draft-ietf-rolc-nhrp-08.txt   draft-ietf-rolc-nhrp-09.txt 
Routing over Large Clouds Working Group James V. Luciani Routing over Large Clouds Working Group James V. Luciani
INTERNET-DRAFT (Bay Networks) INTERNET-DRAFT (Bay Networks)
<draft-ietf-rolc-nhrp-08.txt> Dave Katz <draft-ietf-rolc-nhrp-09.txt> Dave Katz
(cisco Systems) (cisco Systems)
David Piscitello David Piscitello
(Core Competence, Inc.) (Core Competence, Inc.)
Bruce Cole Bruce Cole
(cisco Systems) (cisco Systems)
Expires December 1996 Expires January 1997
NBMA Next Hop Resolution Protocol (NHRP) NBMA Next Hop Resolution Protocol (NHRP)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
itself. Otherwise, the NBMA next hop is the egress router from the itself. Otherwise, the NBMA next hop is the egress router from the
NBMA subnetwork that is "nearest" to the destination station. NBMA subnetwork that is "nearest" to the destination station.
One way to model an NBMA network is by using the notion of logically 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 independent IP subnets (LISs). LISs, as defined in [3] and [4], have
the following properties: the following properties:
1) All members of a LIS have the same IP network/subnet number 1) All members of a LIS have the same IP network/subnet number
and address mask. and address mask.
2) All members within a LIS are directly connected to the same 2) All members of a LIS are directly connected to the same
NBMA subnetwork. NBMA subnetwork.
3) All members outside of the LIS are accessed via a router. 3) All hosts and routers outside of the LIS are accessed via a router.
4) All members within the LIS access each other directly 4) All members of a LIS access each other directly (without routers).
(without routers)
Address resolution as described in [3] and [4] only resolves the next 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 hop address if the destination station is a member of the same LIS as
the source station; otherwise, the source station must forward the source station; otherwise, the source station must forward
packets to a router that is a member of multiple LIS's. In multi-LIS packets to a router that is a member of multiple LIS's. In multi-LIS
configurations, hop-by-hop address resolution may not be sufficient configurations, hop-by-hop address resolution may not be sufficient
to resolve the "NBMA next hop" toward the destination station, and IP to resolve the "NBMA next hop" toward the destination station, and IP
packets may have multiple IP hops through the NBMA subnetwork. packets may have multiple IP hops through the NBMA subnetwork.
Another way to model NBMA is by using the notion of Local Address Another way to model NBMA is by using the notion of Local Address
skipping to change at page 3, line 20 skipping to change at page 3, line 19
Support for the LAG model assumes the existence of a mechanism that 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 allows any entity (i.e., host or router) connected to an NBMA network
to resolve an internetworking layer address to an NBMA address for to resolve an internetworking layer address to an NBMA address for
any other entity connected to the same NBMA network. This resolution any other entity connected to the same NBMA network. This resolution
would take place regardless of the address assignments to these would take place regardless of the address assignments to these
entities. NHRP describes such a mechanism. For example, when the entities. NHRP describes such a mechanism. For example, when the
internetworking layer address is of type IP, once the NBMA next hop internetworking layer address is of type IP, once the NBMA next hop
has been resolved, the source may either start sending IP packets to has been resolved, the source may either start sending IP packets to
the destination (in a connectionless NBMA subnetwork such as SMDS) or the destination (in a connectionless NBMA subnetwork such as SMDS) or
may first establish a connection to the destination with the desired may first establish a connection to the destination with the desired
bandwidth and QOS characteristics (in a connection-oriented NBMA bandwidth (in a connection-oriented NBMA subnetwork such as ATM).
subnetwork such as ATM).
Use of NHRP may be sufficient for hosts doing address resolution when Use of NHRP may be sufficient for hosts doing address resolution when
those hosts are directly connected to an NBMA subnetwork, allowing those hosts are directly connected to an NBMA subnetwork, allowing
for straightforward implementations in NBMA stations. NHRP also has for straightforward implementations in NBMA stations. NHRP also has
the capability of determining the egress point from an NBMA the capability of determining the egress point from an NBMA
subnetwork when the destination is not directly connected to the NBMA subnetwork when the destination is not directly connected to the NBMA
subnetwork and the identity of the egress router is not learned by subnetwork and the identity of the egress router is not learned by
other methods (such as routing protocols). Optional extensions to other methods (such as routing protocols). Optional extensions to
NHRP provide additional robustness and diagnosability. NHRP provide additional robustness and diagnosability.
skipping to change at page 5, line 4 skipping to change at page 4, line 45
For administrative and policy reasons, a physical NBMA subnetwork may For administrative and policy reasons, a physical NBMA subnetwork may
be partitioned into several, disjoint "Logical NBMA subnetworks". A be partitioned into several, disjoint "Logical NBMA subnetworks". A
Logical NBMA subnetwork is defined as a collection of hosts and Logical NBMA subnetwork is defined as a collection of hosts and
routers that share unfiltered subnetwork connectivity over an NBMA routers that share unfiltered subnetwork connectivity over an NBMA
subnetwork. "Unfiltered subnetwork connectivity" refers to the subnetwork. "Unfiltered subnetwork connectivity" refers to the
absence of closed user groups, address screening or similar features absence of closed user groups, address screening or similar features
that may be used to prevent direct communication between stations that may be used to prevent direct communication between stations
connected to the same NBMA subnetwork. (Hereafter, unless otherwise connected to the same NBMA subnetwork. (Hereafter, unless otherwise
specified, we use the term "NBMA subnetwork" to mean *logical* NBMA specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
subnetwork.) subnetwork.)
Placed within the NBMA subnetwork are one or more entities that Placed within the NBMA subnetwork are one or more entities that
implement the NHRP protocol. Such stations which are capable of implement the NHRP protocol. Such stations which are capable of
answering Next Hop Resolution Requests are known as "Next Hop answering NHRP Resolution Requests are known as "Next Hop Servers"
Servers" (NHSs). Each NHS serves a set of destination hosts, which (NHSs). Each NHS serves a set of destination hosts, which may or may
may or may not be directly connected to the NBMA subnetwork. NHSs not be directly connected to the NBMA subnetwork. NHSs cooperatively
cooperatively resolve the NBMA next hop within their logical NBMA resolve the NBMA next hop within their logical NBMA subnetwork. In
subnetwork. In addition to NHRP, NHSs may participate in protocols addition to NHRP, NHSs may support "classical" ARP service; however,
used to disseminate routing information across (and beyond the this will be the subject of a separate document.
boundaries of) the NBMA subnetwork, and may support "classical" ARP
service as well.
An NHS maintains a "next-hop resolution" cache, which is a table of
address mappings (internetwork layer address to NBMA subnetwork layer
address). This table can be constructed from information gleaned
from NHRP Register packets (see Section 5.2.3 and 5.2.4), extracted
from Next Hop Resolution Requests/Replies that traverse the NHS as
they are forwarded, or through mechanisms outside the scope of this
document (examples of such mechanisms include ARP [2, 3, 4] and pre-
configured tables). Section 6.2 further describes cache management
issues.
A host or router that is not an NHRP server must be configured with
the identity of the NHS which serves it (see Configuration, Section
4).
[Note: for NBMA subnetworks that offer group or multicast addressing An NHS maintains a cache which contains protocol layer address to
features, it may be desirable to configure stations with a group NBMA subnetwork layer address resolution information. This cache can
identity for NHSs, i.e., addressing information that would solicit a be constructed from information obtained from NHRP Register packets
response from "all NHSs". The means whereby a group of NHSs divide (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
responsibilities for next hop resolution are not described here.] 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.
Whether or not a particular station within the NBMA subnetwork which For a station within a given LIS to avoid providing NHS
is making use of the NHRP protocol needs to be able to act as an NHS
is a local matter. For a station to avoid providing NHS
functionality, there must be one or more NHSs within the NBMA functionality, there must be one or more NHSs within the NBMA
subnetwork which are providing authoritative NBMA information on its subnetwork which are providing authoritative address resolution
behalf. If NHRP is to be able to resolve the NBMA address for information on its behalf. Such an NHS is said to be "serving" the
stations that lack NHS functionality, these serving NHSs must exist station. A stations on a LIS that lacks NHS functionality and is a
along all routed paths between Next Hop Resolution Requesters and the client of the NHRP service is known as NHRP Client or just NHCs. If
station which cannot answer Next Hop Resolution Requests. 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.
The protocol proceeds as follows. An event occurs triggering station 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 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 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 emitted from station S (either because station S is a host, or
station S is a transit router), but the address resolution could also station S is a transit router), but the address resolution could also
be triggered by other means (a routing protocol update packet, for be triggered by other means (a routing protocol update packet, for
example). Station S first determines the next hop to station D example). Station S first determines the next hop to station D
through normal routing processes (for a host, the next hop may simply 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 be the default router; for routers, this is the "next hop" to the
destination internetwork layer address). If the next hop is destination internetwork layer address). If the destination's
reachable through one of its NBMA interfaces, S constructs an Next address resolution information is already available in S's cache then
Hop Resolution Request packet (see Section 5.2.1) containing station that information is used to forward the packet. Otherwise, if the
D's internetwork layer address as the (target) destination address, next hop is reachable through one of its NBMA interfaces, S
S's own internetwork layer address as the source address (Next Hop constructs an NHRP Resolution Request packet (see Section 5.2.1)
Resolution Request initiator), and station S's NBMA addressing containing station D's internetwork layer address as the (target)
information. Station S may also indicate that it prefers an destination address, S's own internetwork layer address as the source
authoritative Next Hop Resolution Reply (i.e., station S only wishes address (Next Hop Resolution Request initiator), and station S's NBMA
to receive a Next Hop Resolution Reply from the NHS-speaker that addressing information. Station S may also indicate that it prefers
maintains the NBMA-to-internetwork layer address mapping for this an authoritative NHRP Resolution Reply (i.e., station S only wishes
destination). Station S emits the Next Hop Resolution Request packet to receive an NHRP Resolution Reply from an NHS serving the
destination NHC). Station S emits the NHRP Resolution Request packet
towards the destination. towards the destination.
If the Next Hop Resolution Request is triggered by a data packet, If the NHRP Resolution Request is triggered by a data packet then S
station S may choose to dispose of the data packet while awaiting a may, while awaiting an NHRP Resolution Reply, choose to dispose of
Next Hop Resolution Reply in one of the following ways: the data packet in one of the following ways:
(a) Drop the packet (a) Drop the packet
(b) Retain the packet until the Next Hop Resolution Reply arrives (b) Retain the packet until the NHRP Resolution Reply arrives
and a more optimal path is available and a more optimal path is available
(c) Forward the packet along the routed path toward D (c) Forward the packet along the routed path toward D
The choice of which of the above to perform is a local policy matter, 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 though option (c) is the recommended default, since it may allow data
to flow to the destination while the NBMA address is being resolved. to flow to the destination while the NBMA address is being resolved.
Note that an Next Hop Resolution Request for a given destination MUST Note that an NHRP Resolution Request for a given destination MUST NOT
NOT be triggered on every packet, though periodically retrying a Next be triggered on every packet.
Hop Resolution Request is permitted.
When the NHS receives an Next Hop Resolution Request, a check is made When the NHS receives an NHRP Resolution Request, a check is made to
to see if it "serves" station D, i.e., the NHS checks to see if there see if it serves station D. If the NHS does not serve D, the NHS
is a "next hop" entry for D in its next-hop resolution cache. If the forwards the NHRP Resolution Request to another NHS. Mechanisms for
NHS does not serve D, the NHS forwards the Next Hop Resolution determining how to forward the NHRP Resolution Request are discussed
Request to another NHS. (Mechanisms for determining how to forward in Section 3.
the Next Hop Resolution Request are discussed in Section 3,
Deployment.) Note that NHSs must be next hops to one another in order
for forwarding of NHRP packets to be possible.
If this NHS serves D, the NHS resolves station D's NBMA address, and If this NHS serves D, the NHS resolves station D's NBMA address
generates a positive Next Hop Resolution Reply (denoted by a 0 Code information, and generates a positive NHRP Resolution Reply on D's
in the reply) on D's behalf. (Next Hop Resolution Replies in this behalf. NHRP Resolution Replies in this scenario are always marked
scenario are always marked as "authoritative".) The Next Hop as "authoritative". The NHRP Resolution Reply packet contains the
Resolution Reply packet contains the next hop internetwork layer address resolution information for station D which is to be sent back
address and the NBMA address for station D and is sent back to S. to S. Note that if station D is not on the NBMA subnetwork, the next
(Note that if station D is not on the NBMA subnetwork, the next hop hop internetwork layer address will be that of the egress router
internetwork layer address will be that of the egress router through through which packets for station D are forwarded.
which packets for station D are forwarded.)
An NHS receiving a Next Hop Resolution Reply may cache the NBMA next A transit NHS receiving an NHRP Resolution Reply may cache the
hop information contained therein. To a subsequent Next Hop address resolution information contained therein. To a subsequent
Resolution Request, this NHS may respond with the cached, non- NHRP Resolution Request, this NHS may respond with the cached, "non-
authoritative, NBMA next hop information or with cached negative authoritative" address resolution information if the NHS is permitted
information, if the NHS is allowed to do so, see section 5.2.2 and to do so (see Sections 5.2.2 and 6.2 for more information on non-
6.2. Non-authoritative Next Hop Resolution Replies are distinguished authoritative versus authoritative NHRP Resolution Replies). Non-
from authoritative Next Hop Resolution Replies so that if a authoritative NHRP Resolution Replies are distinguished from
communication attempt based on non-authoritative information fails, a authoritative NHRP Resolution Replies so that if a communication
source station can choose to send an authoritative Next Hop attempt based on non-authoritative information fails, a source
Resolution Request. NHSs MUST NOT respond to authoritative Next Hop station can choose to send an authoritative NHRP Resolution Request.
Resolution Requests with cached information. NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
cached information.
[Note: An Next Hop Resolution Reply can be returned directly to the An NHRP Resolution Reply may be returned directly to the NHRP
Next Hop Resolution Request initiator, i.e., without traversing the Resolution Request initiator, without traversing the NHSs which
list of NHSs that forwarded the Next Hop Resolution Request, if all forwarded the NHRP Resolution Request, if each of the following
of the following criteria are satisfied: criteria are satisfied:
(a) Direct communication is available via datagram transfer (a) Direct communication is available via datagram transfer
(e.g., SMDS) or the NHS has an existing virtual circuit (e.g., SMDS) or the NHS has an existing virtual circuit
connection to the Next Hop Resolution Request initiator or is connection to the NHC which sent the NHRP Resolution Request
permitted to open one. or NHS is permitted to open a connection the NHC.
(b) The Next Hop Resolution Request initiator has not included the (b) The NHRP Resolution Request initiator has not included the
NHRP Reverse NHS record Extension (see Section 5.3.5). NHRP Reverse NHS record Extension (see Section 5.3.3).
(c) The authentication policy in force permits direct (c) The authentication policy in force permits direct
communication between the NHS and the Next Hop Resolution communication between the NHS and the NHRP Resolution
Request initiator. Request initiator.
The purpose of allowing an NHS to send a Next Hop Resolution Reply The purpose of allowing an NHS to send a NHRP Resolution Reply
directly is to reduce response time. A consequence of allowing a directly is to reduce response time. A consequence of allowing a
direct Next Hop Resolution Reply is that NHSs that would under direct NHRP Resolution Reply is that NHSs that would under normal
normal circumstances be traversed by the Next Hop Resolution Reply circumstances be traversed by the NHRP Resolution Reply would not
would not cache next hop information contained therein.] cache next hop information contained therein. This feature may have
value when the serving NHS is an egress router for the destination
address which is off the NBMA cloud (this implies that NHC
functionality is coresident with the NHS).
The process of forwarding the Next Hop Resolution Request is repeated If the determination is made that no NHS in the NBMA subnetwork can
until the Next Hop Resolution Request is satisfied, or an error reply to the NHRP Resolution Request for D then a negative NHRP
occurs (e.g., no NHS in the NBMA subnetwork can resolve the Next Hop Resolution Reply (NAK) is returned. This occurs when (a) no next-hop
Resolution Request.) If the determination is made that station D's resolution information is available for station D from any NHS, or
next hop cannot be resolved, a negative Next Hop Resolution Reply (b) an NHS is unable to forward the NHRP Resolution Request (e.g.,
(NAK) is returned. This occurs when (a) no next-hop resolution connectivity is lost).
information is available for station D from any NHS, or (b) an NHS is
unable to forward the Next Hop Resolution Request (e.g., connectivity
is lost).
NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
and NHRP Error Indications follow the routed path from sender to and NHRP Error Indications follow the routed path from sender to
receiver in the same fashion that Next Hop Resolution Requests and receiver in the same fashion that NHRP Resolution Requests and NHRP
Next Hop Resolution Replies do. That is, "requests" and Resolution Replies do. That is, "requests" and "indications" follow
"indications" follow the routed path from Source Protocol Address the routed path from Source Protocol Address (which is the address of
(which is the address of the station initiating the communication) to the station initiating the communication) to the Destination Protocol
the Destination Protocol Address. "Replies", on the other hand, Address. "Replies", on the other hand, follow the routed path from
follow the routed path from the Destination Protocol Address back to the Destination Protocol Address back to the Source Protocol Address
the Source Protocol Address with the exceptions mentioned above where with the exceptions mentioned above where a direct VC may be created.
a direct VC may be created. In the case of a NHRP Registration In the case of a NHRP Registration Reply and in the case of an NHC
Reply, the packet is always returned via a direct VC (see Section initiated NHRP Purge Request, the packet is always returned via a
5.2.4). direct VC (see Sections 5.2.4 and 5.2.5).
NHRP Requests and NHRP Replies MUST NOT cross the borders of a NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
logical NBMA subnetwork (an explicit NBMA subnetwork identifier may subnetwork however further study is being done in this area (see
be included as an extension in the Next Hop Resolution Request, see Section 7). Thus, the internetwork layer traffic out of and into an
section 5.3.2). Thus, the internetwork layer traffic out of and into NBMA subnetwork always traverses an internetwork layer router at its
a logical NBMA subnetwork always traverses an internetwork layer border. Internetwork layer filtering can then be implemented at
router at its border. Internetwork layer filtering can then be these border routers.
implemented at these border routers.
NHRP optionally provides a mechanism to send a Next Hop Resolution NHRP optionally provides a mechanism to send a NHRP Resolution Reply
Reply which contains aggregated NBMA next hop information. Suppose which contains aggregated address resolution information. For
that router X is the NBMA next hop from station S to station D. example, suppose that router X is the next hop from station S to
Suppose further that X is an egress router for all stations sharing station D and that X is an egress router for all stations sharing an
an internetwork layer address prefix with station D. When an Next internetwork layer address prefix with station D. When an NHRP
Hop Resolution Reply is generated in response to a Next Hop Resolution Reply is generated in response to a NHRP Resolution
Resolution Request, the responder may augment the internetwork layer Request, the responder may augment the internetwork layer address of
address of station D with a prefix length (see Section 5.2.0.1). A station D with a prefix length (see Section 5.2.0.1). A subsequent
subsequent (non-authoritative) Next Hop Resolution Request for some (non-authoritative) NHRP Resolution Request for some destination that
destination that shares an internetwork layer address prefix (for the shares an internetwork layer address prefix (for the number of bits
number of bits specified in the prefix length) with D may be specified in the prefix length) with D may be satisfied with this
satisfied with this cached information. See section 6.2 regarding cached information. See section 6.2 regarding caching issues.
caching issues.
To dynamically detect subnetwork-layer filtering in NBMA subnetworks To dynamically detect subnetwork-layer filtering in NBMA subnetworks
(e.g., X.25 closed user group facility, or SMDS address screens), to (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 trace the routed path that an NHRP packet takes, or to provide loop
detection and diagnostic capabilities, a "Route Record" may be detection and diagnostic capabilities, a "Route Record" may be
included in NHRP packets (see Sections 5.3.4 and 5.3.5). The Route included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route
Record extensions contain the internetwork (and subnetwork layer) Record extensions are the NHRP Forward Transit NHS Record Extension
addresses of all intermediate NHSs between source and destination (in and the NHRP Reverse Transit NHS Record Extension. They contain the
the forward direction) and between destination and source (in the internetwork (and subnetwork layer) addresses of all intermediate
reverse direction). When a source station is unable to communicate 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 with the responder (e.g., an attempt to open an SVC fails), it may
attempt to do so successively with other subnetwork layer addresses attempt to do so successively with other subnetwork layer addresses
in the Route Record until it succeeds (if authentication policy in these extensions until it succeeds (if authentication policy
permits such action). This approach can find a suitable egress point permits such action). This approach can find a suitable egress point
in the presence of subnetwork-layer filtering (which may be in the presence of subnetwork-layer filtering (which may be
source/destination sensitive, for instance, without necessarily source/destination sensitive, for instance, without necessarily
creating separate logical NBMA subnetworks) or subnetwork-layer creating separate logical NBMA subnetworks) or subnetwork-layer
congestion (especially in connection-oriented media). congestion (especially in connection-oriented media).
3. Deployment 3. Deployment
Next Hop Resolution Requests traverse one or more hops within an NBMA NHRP Resolution Requests traverse one or more hops within an NBMA
subnetwork before reaching the station that is expected to generate a subnetwork before reaching the station that is expected to generate a
response. Each station, including the source station, chooses a response. Each station, including the source station, chooses a
neighboring NHS to which it will forward the Next Hop Resolution neighboring NHS to which it will forward the NHRP Resolution Request.
Request. The NHS selection procedure typically involves applying a The NHS selection procedure typically involves applying a destination
destination protocol layer address to the protocol layer routing protocol layer address to the protocol layer routing table which
table which causes a routing decision to be returned. This routing causes a routing decision to be returned. This routing decision is
decision is then used to forward the Next Hop Resolution Request to then used to forward the NHRP Resolution Request to the downstream
the downstream NHS. The destination protocol layer address previously NHS. The destination protocol layer address previously mentioned is
mentioned is carried within the Next Hop Resolution Request packet. carried within the NHRP Resolution Request packet. Note that even
Note that even though a protocol layer address was used to acquire a though a protocol layer address was used to acquire a routing
routing decision, NHRP packets are not encapsulated within a protocol decision, NHRP packets are not encapsulated within a protocol layer
layer header but rather are carried at the NBMA layer using the header but rather are carried at the NBMA layer using the
encapsulation described in Section 5. encapsulation described in Section 5.
Each NHS/router examines the Next Hop Resolution Request packet on Each NHS/router examines the NHRP Resolution Request packet on its
its way toward the destination. Each NHS which the NHRP packet way toward the destination. Each NHS which the NHRP packet traverses
traverses on the way to the packet's destination might modify the on the way to the packet's destination might modify the packet (e.g.,
packet (e.g., updating the Forward Record extension). Ignoring error updating the Forward Record extension). Ignoring error situations,
situations, the Next Hop Resolution Request eventually arrives at a the NHRP Resolution Request eventually arrives at a station that is
station that is to generate an Next Hop Resolution Reply. This to generate an NHRP Resolution Reply. This responding station
responding station "serves" the destination. The responding station "serves" the destination. The responding station generates a NHRP
generates a Next Hop Resolution Reply using the source protocol Resolution Reply using the source protocol address from within the
address from within the NHRP packet to determine where the Next Hop NHRP packet to determine where the NHRP Resolution Reply should be
Resolution Reply should be sent. sent.
Rather than use routing to determine the next hop for an NHRP packet, Rather than use routing to determine the next hop for an NHRP packet,
an NHS may use static configuration information (or other applicable an NHS may use static configuration information (or other applicable
means) in order to determine to which neighboring NHSs to forward the means) in order to determine to which neighboring NHSs to forward the
Next Hop Resolution Request packet. The use of static configuration NHRP Resolution Request packet. The use of static configuration
information for this purpose is beyond the scope of this document. information for this purpose is beyond the scope of this document.
In order to forward NHRP packets to a neighboring NHS, NHRP clients
must nominally be configured with the NBMA address of at least one
NHS. In practice, a client's default router should also be its NHS
in that way 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.
The NHS serving a particular destination must lie along the routed The NHS serving a particular destination must lie along the routed
path to that destination. In practice, this means that all egress path to that destination. In practice, this means that all egress
routers must double as NHSs serving the destinations beyond them, and routers must double as NHSs serving the destinations beyond them, and
that hosts on the NBMA subnetwork are served by routers that double that hosts on the NBMA subnetwork are served by routers that double
as NHSs. Also, this implies that forwarding of NHRP packets within as NHSs. Also, this implies that forwarding of NHRP packets within
an NBMA subnetwork requires a contiguous deployment of NHRP capable an NBMA subnetwork requires a contiguous deployment of NHRP capable
routers. During migration to NHRP, it cannot be expected that all routers. During migration to NHRP, it cannot be expected that all
routers within the NBMA subnetwork are NHRP capable. Thus, NHRP routers within the NBMA subnetwork are NHRP capable. Thus, NHRP
traffic which would otherwise need to be forwarded through such traffic which would otherwise need to be forwarded through such
routers can be expected to be dropped due to the NHRP packet not 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 being recognized. In this case, NHRP will be unable to establish any
transit paths whose discovery requires the traversal of the non-NHRP transit paths whose discovery requires the traversal of the non-NHRP
speaking routers. If the client has tried and failed to acquire a speaking routers. If the client has tried and failed to acquire a
cut through path then the client should use the network layer routed cut through path then the client should use the network layer routed
path as a default. path as a default.
If a subnetwork offers a link layer group addressing or multicast If an NBMA technology offers a group, an anycast, or a multicast
feature, the client (station) may be configured with a group address addressing feature then the NHC may be configured with such an
assigned to the group of next-hop servers. The client might then address which would be assigned to the appropriate NHSs. The NHC
submit Next Hop Resolution Requests to the group address, eliciting a might then submit NHRP Resolution Requests to such an address,
response from one or more NHSs, depending on the response strategy eliciting a response from one or more NHSs, depending on the response
selected. Note that the constraints described in Section 2 regarding strategy selected. Note that the constraints described in Section 2
directly sending Next Hop Resolution Reply may apply. regarding directly sending NHRP Resolution Reply may apply.
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 4. Configuration
Clients Next Hop Clients
To participate in NHRP, a client connected to an NBMA subnetwork An NHC connected to an NBMA subnetwork MAY be configured with the
should be configured with the NBMA address(es) of its NHS(s) Protocol address(es) and NBMA address(es) of its NHS(s). The
(alternatively, it should be configured with a means of acquiring NHS(s) will likely also represent the NHC's default or peer
them, i.e., the group address that members of a NHS group use for routers, so their NBMA addresses may be obtained from the NHC's
the purpose of address or next-hop resolution.) The NHS(s) will existing configuration. If the NHC is attached to several
likely also represent the client's default or peer routers, so subnetworks (including logical NBMA subnetworks), the NHC should
their NBMA addresses may be obtained from the client's existing also be configured to receive routing information from its NHS(s)
configuration. If the client is attached to several subnetworks and peer routers so that it can determine which internetwork layer
(including logical NBMA subnetworks), the client should also be networks are reachable through which subnetworks.
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 Next Hop Servers
An NHS is configured with knowledge of its own internetwork layer An NHS is configured with knowledge of its own internetwork layer
and NBMA addresses and a logical NBMA subnetwork identifier (see and NBMA addresses. An NHS MAY also be configured with a set of
Section 5.3.2). An NHS MAY also be configured with a set of
internetwork layer address prefixes that correspond to the internetwork layer address prefixes that correspond to the
internetwork layer addresses of the stations it serves. If a served internetwork layer addresses of the stations it serves. The NBMA
client is attached to several subnetworks, the NHS may also need to addresses of the stations served by the NHS may be learned via NHRP
be configured to advertise routing information to such client. 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 If an NHS acts as an egress router for stations connected to other
subnetworks than the NBMA subnetwork, the NHS must, in addition to subnetworks than the NBMA subnetwork, the NHS must, in addition to
the above, be configured to exchange routing information between the above, be configured to exchange routing information between
the NBMA subnetwork and these other subnetworks. the NBMA subnetwork and these other subnetworks.
In all cases, routing information is exchanged using conventional In all cases, routing information is exchanged using conventional
intra-domain and/or inter-domain routing protocols. intra-domain and/or inter-domain routing protocols.
The NBMA addresses of the stations served by the NHS may be learned
via NHRP Register packets or manual configuration.
5. NHRP Packet Formats 5. NHRP Packet Formats
This section describes the format of NHRP packets. In the following, This section describes the format of NHRP packets. In the following,
unless otherwise stated explicitly, the unqualified term "request" unless otherwise stated explicitly, the unqualified term "request"
refers generically to any of the NHRP packet types which are refers generically to any of the NHRP packet types which are
"requests". Further, unless otherwise stated explicitly, the "requests". Further, unless otherwise stated explicitly, the
unqualified term "reply" refers generically to any of the NHRP packet unqualified term "reply" refers generically to any of the NHRP packet
types which are "replies". types which are "replies".
An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 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. Extensions Part. The Fixed Part is common to all NHRP packet types.
skipping to change at page 13, line 52 skipping to change at page 14, line 9
This field identifies the existence and location of NHRP This field identifies the existence and location of NHRP
extensions. If this field is 0 then no extensions exist otherwise extensions. If this field is 0 then no extensions exist otherwise
this field represents the offset from the beginning of the NHRP this field represents the offset from the beginning of the NHRP
packet (i.e., starting from the ar$afn field) of the first packet (i.e., starting from the ar$afn field) of the first
extension. extension.
ar$op.version ar$op.version
This field is set to 0x01 for NHRP version 1. This field is set to 0x01 for NHRP version 1.
ar$op.type ar$op.type
This is the NHRP packet type: NHRP Next Hop Resolution Request(1), This is the NHRP packet type: NHRP Resolution Request(1), NHRP
NHRP Next Hop Resolution Reply(2), NHRP Registration Request(3), Resolution Reply(2), NHRP Registration Request(3), NHRP
NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6),
Reply(6), or NHRP Error Indication(7). Use of NHRP packet Types in or NHRP Error Indication(7). Use of NHRP packet Types in the range
the range 128 to 255 are reserved for research or use in other 128 to 255 are reserved for research or use in other protocol
protocol development and will be administered by IANA. development and will be administered by IANA.
ar$shtl ar$shtl
Type & length of source NBMA address interpreted in the context of Type & length of source NBMA address interpreted in the context of
the 'address family number'[6] indicated by ar$afn (e.g., the 'address family number'[6] indicated by ar$afn (e.g.,
ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F
(E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl (E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl
must be coded appropriately (see below). must be coded appropriately (see below).
ar$sstl ar$sstl
Type & length of source NBMA subaddress interpreted in the context Type & length of source NBMA subaddress interpreted in the context
skipping to change at page 15, line 8 skipping to change at page 15, line 13
then ar$afn MUST be set to 0x000F which means that if a subaddress then ar$afn MUST be set to 0x000F which means that if a subaddress
exists then it is of type NSAP. exists then it is of type NSAP.
The bottom 6 bits is an unsigned integer value indicating the length 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 of the associated NBMA address in octets. If this value is zero the
flag x is ignored. flag x is ignored.
5.2.0 Mandatory Part 5.2.0 Mandatory Part
The Mandatory Part of the NHRP packet contains the operation specific The Mandatory Part of the NHRP packet contains the operation specific
information (e.g., Next Hop Resolution Request/Reply, etc.) and information (e.g., NHRP Resolution Request/Reply, etc.) and variable
variable length data which is pertinent to the packet type. length data which is pertinent to the packet type.
5.2.0.1 Mandatory Part Format 5.2.0.1 Mandatory Part Format
Sections 5.2.1 through 5.2.6 have a very similar mandatory part. 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 This mandatory part includes a common header and zero or more Client
Information Entries (CIEs). Section 5.2.7 has a different format Information Entries (CIEs). Section 5.2.7 has a different format
which is specified in that section. which is specified in that section.
The common header looks like the following: The common header looks like the following:
skipping to change at page 18, line 4 skipping to change at page 18, line 4
Code Code
This field is message specific. See the relevant message sections This field is message specific. See the relevant message sections
below. In general, this field is a NAK code; i.e., when the field 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 is 0 in a reply then the packet is acknowledging a request and if
it contains any other value the packet contains a negative it contains any other value the packet contains a negative
acknowledgment. acknowledgment.
Prefix Length Prefix Length
This field is message specific. See the relevant message sections This field is message specific. See the relevant message sections
below. In general, however, this fields is used to indicate that below. In general, however, this fields is used to indicate that
the information carried in an NHRP the message pertains to an the information carried in an NHRP message pertains to an
equivalence class of internetwork layer addresses rather than just equivalence class of internetwork layer addresses rather than just
a single internetwork layer address specified. All internetwork a single internetwork layer address specified. All internetwork
layer addresses that match the first "Prefix Length" bit positions layer addresses that match the first "Prefix Length" bit positions
for the specific internetwork layer address are included in the for the specific internetwork layer address are included in the
equivalence class. 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 Maximum Transmission Unit
This field gives the maximum transmission unit for the relevant This field gives the maximum transmission unit for the relevant
client station. If this value is 0 then either the default MTU is client station. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA. negotiation is possible for the given NBMA.
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the Next Hop NBMA information specified in the CIE is considered to the Next Hop NBMA information specified in the CIE is considered to
skipping to change at page 19, line 15 skipping to change at page 19, line 18
Client Protocol Address Client Protocol Address
This is the client's internetworking layer address specified. This is the client's internetworking layer address specified.
Note that an NHS SHOULD NOT cache source information which is in an Note that an NHS SHOULD NOT cache source information which is in an
NHRP message because this information could be inappropriately used NHRP message because this information could be inappropriately used
to set up a cut-through without doing proper filtering along a routed to set up a cut-through without doing proper filtering along a routed
path. Further, in the case where a distributed router exists in the path. Further, in the case where a distributed router exists in the
network, incorrect or incomplete information may be included in the network, incorrect or incomplete information may be included in the
source information. source information.
5.2.1 NHRP Next Hop Resolution Request 5.2.1 NHRP Resolution Request
The NHRP Next Hop Resolution Request packet has a Type code of 1. Its 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 mandatory part is coded as described in Section 5.2.0.1 and the
specific meanings of the fields are as follows: message specific meanings of the fields are as follows:
Flags - The flags field is coded as follows: Flags - The flags field is coded as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|B|U| unused | |Q|A|B|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Q
Set if the station sending the Next Hop Resolution Request is a Set if the station sending the NHRP Resolution Request is a
router; clear if the it is a host. router; clear if the it is a host.
A A
This bit is set in a Next Hop Resolution Request if only This bit is set in a NHRP Resolution Request if only
authoritative next hop information is desrired and is clear authoritative next hop information is desired and is clear
otherwise. See the NHRP Next Hop Resolution Reply section below otherwise. See the NHRP Resolution Reply section below for
for further details on the "A" bit and its usage. further details on the "A" bit and its usage.
B B
Unused (clear on transmit) Unused (clear on transmit)
U U
This is the Uniqueness bit. This bit aids in duplicate address This is the Uniqueness bit. This bit aids in duplicate address
detection. When this bit is set in an NHRP Resolution Request detection. When this bit is set in an NHRP Resolution Request
and one or more entries exist in the NHS cache which meet the and one or more entries exist in the NHS cache which meet the
requirements of the NHRP Resolution Request then only the CIE in requirements of the NHRP Resolution Request then only the CIE in
the NHS's cache with this bit set will be returned. Note that the NHS's cache with this bit set will be returned. Note that
skipping to change at page 20, line 16 skipping to change at page 20, line 19
then the NHRP Resolution Reply returns with a NAK code of "13 - 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 Binding Exists But Is Not Unique" and no CIE is included. If a
client wishes to receive non- unique Next Hop Entries, then client wishes to receive non- unique Next Hop Entries, then
the client must have the "uniqueness" bit set to zero in its NHRP 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 Resolution Request. Note that when this bit is set in an NHRP
Registration Request, only a single CIE may be specified in the Registration Request, only a single CIE may be specified in the
NHRP Registration Request and that CIE must have the Prefix NHRP Registration Request and that CIE must have the Prefix
Length field set to 0xFF. Length field set to 0xFF.
Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
Next Hop Resolution Request. If one is specified then that entry Resolution Request. If one is specified then that entry carries the
carries the pertinent information for the client sourcing the NHRP pertinent information for the client sourcing the NHRP Resolution
Next Hop Resolution Request. Usage of the CIE in the NHRP Next Hop Request. Usage of the CIE in the NHRP Resolution Request is
Resolution Request is described below: described below:
Prefix Length Prefix Length
If a CIE is specified in the NHRP Next Hop Resolution Request If a CIE is specified in the NHRP Resolution Request then the
then the Prefix Length field may be used to qualify the widest Prefix Length field may be used to qualify the widest acceptable
acceptable prefix which may be used to satisfy the NHRP Next Hop prefix which may be used to satisfy the NHRP Resolution Request.
Resolution Request. In the case of NHRP Next Hop Resolution In the case of NHRP Resolution Request/Reply, the Prefix Length
Request/Reply, the Prefix Length specifies the equivalence class specifies the equivalence class of addresses which match the
of addresses which match the first "Prefix Length" bit positions first "Prefix Length" bit positions of the Destination Protocol
of the Destination Protocol Address. If this field is set to Address. If the "U" bit is set in the common header then this
0x00 then this field MUST be ignored. If the "U" bit is set in field MUST be set to 0xFF.
the common header then this field MUST be set to 0xFF.
Maximum Transmission Unit Maximum Transmission Unit
This field gives the maximum transmission unit for the source This field gives the maximum transmission unit for the source
station. A possible use of this field in the Next Hop Resolution station. A possible use of this field in the NHRP Resolution
Request packet is for the Next Hop Resolution Requester to ask Request packet is for the NHRP Resolution Requester to ask for a
for a target MTU. In lieu of that usage, the CIE must be omitted. target MTU. In lieu of that usage, the CIE must be omitted.
All other fields in the CIE MUST be ignored and SHOULD be set to 0. All other fields in the CIE MUST be ignored and SHOULD be set to 0.
5.2.2 NHRP Next Hop Resolution Reply 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).
The NHRP Next Hop Resolution Reply packet has a Type code of 2. CIEs 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 correspond to Next Hop Entries in an NHS's cache which match the
criteria in the NHRP Next Hop Resolution Request. Its mandatory part is criteria in the NHRP Resolution Request. Its mandatory part is coded
coded as described in Section 5.2.0.1. The message specific meanings of as described in Section 5.2.0.1. The message specific meanings of
the fields are as follows: the fields are as follows:
Flags - The flags field is coded as follows: Flags - The flags field is coded as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|B|U| unused | |Q|A|B|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q Q
Copied from the Next Hop Resolution Request. Set if the Next Hop Copied from the NHRP Resolution Request. Set if the NHRP
Resolution Requester is a router; clear if it is a host. Resolution Requester is a router; clear if it is a host.
A A
Set if the next hop CIE in the Next Hop Resolution Reply is Set if the next hop CIE in the NHRP Resolution Reply is
authoritative; clear if the Next Hop Resolution Reply is non- authoritative; clear if the NHRP Resolution Reply is non-
authoritative. authoritative.
When an NHS receives a Next Hop Resolution Request for When an NHS receives a NHRP Resolution Request for authoritative
authoritative information for which it is the authoritative information for which it is the authoritative source, it MUST
source, it MUST respond with a Next Hop Resolution Reply respond with a NHRP Resolution Reply containing all and only
containing all and only those next hop CIEs which are contained those next hop CIEs which are contained in the NHS's cache which
in the NHS's cache which both match the criteria of the Next Hop both match the criteria of the NHRP Resolution Request and are
Resolution Request and are authoritative cache entries. An NHS authoritative cache entries. An NHS is an authoritative source
is an authoritative source for a Next Hop Resolution Request if for a NHRP Resolution Request if the information in the NHS's
the information in the NHS's cache matches the Next Hop cache matches the NHRP Resolution Request criteria and that
Resolution Request criteria and that information was obtained information was obtained through a NHRP Registration Request or
through a NHRP Registration Request or through synchronization through synchronization with an NHS which obtained this
with an NHS which obtained this information through a NHRP information through a NHRP Registration Request. An
Registration Request. An authoritative cache entry is one which authoritative cache entry is one which is obtained through a NHRP
is obtained through a NHRP Registration Request or through Registration Request or through synchronization with an NHS which
synchronization with an NHS which obtained this information obtained this information through a NHRP Registration Request.
through a NHRP Registration Request.
An NHS obtains non-authoriative CIEs through promiscuous An NHS obtains non-authoriative CIEs through promiscuous
listening to NHRP packets other than NHRP Registrations which are listening to NHRP packets other than NHRP Registrations which are
directed at it. A Next Hop Resolution Request which indicates a directed at it. A NHRP Resolution Request which indicates a
request for non-authoritative information should cause a Next Hop request for non-authoritative information should cause a NHRP
Resolution Reply which contains all entries in the replying NHS's Resolution Reply which contains all entries in the replying NHS's
cache (i.e., both authoritative and non-authoritative) which cache (i.e., both authoritative and non-authoritative) which
match the criteria specified in the request. match the criteria specified in the request.
B B
Set if the association between the destination and the next hop Set if the association between the destination and the next hop
information is guaranteed to be stable for the lifetime of the information is guaranteed to be stable for the lifetime of the
information (the holding time). This is the case if the Next Hop information (the holding time). This is the case if the Next Hop
protocol address identifies the destination (though it may be protocol address identifies the destination (though it may be
different in value than the Destination address if the different in value than the Destination address if the
skipping to change at page 22, line 14 skipping to change at page 22, line 20
when the destination is immediately adjacent to the egress router when the destination is immediately adjacent to the egress router
through a non-NBMA interface). This information affects caching through a non-NBMA interface). This information affects caching
strategies (see section 6.2). strategies (see section 6.2).
U U
This is the Uniqueness bit. See the NHRP Resolution Request This is the Uniqueness bit. See the NHRP Resolution Request
section above for details. When this bit is set only, only one section above for details. When this bit is set only, only one
CIE is included since only one unique binding should exist in an CIE is included since only one unique binding should exist in an
NHS's cache. NHS's cache.
One or more CIEs are specified in the NHRP Next Hop Resolution Reply. One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
Each CIE contains NHRP next hop information which the responding NHS contains NHRP next hop information which the responding NHS has
has cached and which matches the parameters specified in the NHRP cached and which matches the parameters specified in the NHRP
Next Hop Resolution Request. If no match is found by the NHS issuing Resolution Request. If no match is found by the NHS issuing the NHRP
the NHRP Next Hop Resolution Reply then a single CIE is enclosed with Resolution Reply then a single CIE is enclosed with the a CIE Code
the a CIE Code set appropriately (see below) and all other fields set appropriately (see below) and all other fields MUST be ignored
MUST be ignored and SHOULD be set to 0. In order to facilitate the and SHOULD be set to 0. In order to facilitate the use of NHRP by
use of NHRP by minimal client implementations, the first CIE MUST minimal client implementations, the first CIE MUST contain the next
contain the next hop with the highest preference value so that such hop with the highest preference value so that such an implementation
an implementation need parse only a single CIE. need parse only a single CIE.
Code Code
If this field is set to zero then this packet contains a If this field is set to zero then this packet contains a
positively acknowledged NHRP Resolution Reply. If this field positively acknowledged NHRP Resolution Reply. If this field
contains any other value then this message contains an NHRP contains any other value then this message contains an NHRP
Resolution Reply NAK which means that an appropriate Resolution Reply NAK which means that an appropriate
internetworking layer to NBMA address binding was not available internetworking layer to NBMA address binding was not available
in the responding NHS's cache. If NHRP Resolution Reply contains in the responding NHS's cache. If NHRP Resolution Reply contains
a Client Information Entry with a NAK Code other than 0 then it a Client Information Entry with a NAK Code other than 0 then it
MUST NOT contain any other CIE. Currently defined NAK Codes are MUST NOT contain any other CIE. Currently defined NAK Codes are
skipping to change at page 22, line 50 skipping to change at page 23, line 8
layer address to NBMA address bindings found in the responding layer address to NBMA address bindings found in the responding
NHS's cache. NHS's cache.
13 - Binding Exists But Is Not Unique 13 - Binding Exists But Is Not Unique
This code states that there were one or more internetworking This code states that there were one or more internetworking
layer address to NBMA address bindings found in the responding layer address to NBMA address bindings found in the responding
NHS's cache, however none of them had the uniqueness bit set. NHS's cache, however none of them had the uniqueness bit set.
Prefix Length Prefix Length
In the case of NHRP Next Hop Resolution Reply, the Prefix Length In the case of NHRP Resolution Reply, the Prefix Length specifies
specifies the equivalence class of addresses which match the the equivalence class of addresses which match the first "Prefix
first "Prefix Length" bit positions of the Destination Protocol Length" bit positions of the Destination Protocol Address.
Address.
Holding Time Holding Time
The Holding Time specified in a CIE of an NHRP Resolution Reply The Holding Time specified in a CIE of an NHRP Resolution Reply
is the amount of time remaining before the expiration of the is the amount of time remaining before the expiration of the
client information which is cached at the replying NHS. It is client information which is cached at the replying NHS. It is
not the value which was registered by the client. not the value which was registered by the client.
The remainder of the fields for the CIE for each next hop are 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 filled out as they were defined when the next hop was registered
with the responding NHS (or one of the responding NHS's with the responding NHS (or one of the responding NHS's
synchronized servers) via the NHRP Registration Request. synchronized servers) via the NHRP Registration Request.
Load-splitting may be performed when more than one Client Information Load-splitting may be performed when more than one Client Information
Entry is returned to a requester when equal preference values are Entry is returned to a requester when equal preference values are
specified. Also, the alternative addresses may be used in case of specified. Also, the alternative addresses may be used in case of
connectivity failure in the NBMA subnetwork (such as a failed call connectivity failure in the NBMA subnetwork (such as a failed call
attempt in connection-oriented NBMA subnetworks). attempt in connection-oriented NBMA subnetworks).
Any extensions present in the Next Hop Resolution Request packet MUST Any extensions present in the NHRP Resolution Request packet MUST be
be present in the NHRP Next Hop Resolution Reply even if the present in the NHRP Resolution Reply even if the extension is non-
extension is non-Compulsory. Compulsory.
If an unsolicited NHRP Next Hop Resolution Reply packet is received, If an unsolicited NHRP Resolution Reply packet is received, an Error
an Error Indication of type Invalid Next Hop Resolution Reply Indication of type Invalid NHRP Resolution Reply Received SHOULD be
Received SHOULD be sent in response. 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).
5.2.3 NHRP Registration Request 5.2.3 NHRP Registration Request
The NHRP Registration Request is sent from a station to an NHS to 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 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 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 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 is coded as described in Section 5.2.0.1. The message specific
meanings of the fields are as follows: meanings of the fields are as follows:
skipping to change at page 25, line 7 skipping to change at page 25, line 16
Code Code
This field is set to 0x00 in NHRP Registration Requests. This field is set to 0x00 in NHRP Registration Requests.
Prefix Length Prefix Length
This field may be used in a NHRP Registration Request to register This field may be used in a NHRP Registration Request to register
equivalence information for the Client Protocol Address specified equivalence information for the Client Protocol Address specified
in the CIE of an NHRP Registration Request In the case of NHRP in the CIE of an NHRP Registration Request In the case of NHRP
Registration Request, the Prefix Length specifies the equivalence Registration Request, the Prefix Length specifies the equivalence
class of addresses which match the first "Prefix Length" bit class of addresses which match the first "Prefix Length" bit
positions of the Client Protocol Address. If this field is set positions of the Client Protocol Address. If the "U" bit is set
to 0x00 then this field MUST be ignored and no equivalence in the common header then this field MUST be set to 0xFF.
information is assumed (i.e., only Client Protocol Address is
bound to the NBMA information). If the "U" bit is set in the
common header then this field MUST be set to 0xFF.
This packet is used to register a station's NHRP information with its The NHRP Registration Request is used to register an NHC's NHRP
NHSs, as configured or known through conventional routing means. information with its NHSs. If an NHC is configured with the protocol
NHSs may also be configured with the identities of stations that they address of a serving NHS then the NHC may place the NHS's protocol
serve. If an NHS receives an NHRP Registration Request packet which address in the Destination Protocol Address field of the NHRP
has the Destination Protocol Address field set to an address other Registration Request common header otherwise the NHC must place its
than the NHS's own protocol address then the NHS MUST forward the own protocol address in the Destination Protocol Address field.
packet along the routed path toward the Destination Protocol Address.
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.
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 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 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 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 reply with a NAK-ed Registration Reply of type Can't Serve This
Address. Address.
If an NHS cannot serve a station due to a lack of resources, the NHS 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 MUST reply with a NAK-ed Registration Reply of type Registration
Overflow. Overflow.
skipping to change at page 26, line 14 skipping to change at page 26, line 44
Registration Request may fail for various reasons. If this is the Registration Request may fail for various reasons. If this is the
case then each failed attempt to register the information in a CIE of case then each failed attempt to register the information in a CIE of
an NHRP Registration Request is logged in the associated NHRP an NHRP Registration Request is logged in the associated NHRP
Registration Reply by setting the CIE Code field to the appropriate Registration Reply by setting the CIE Code field to the appropriate
error code as shown below: error code as shown below:
CIE Code CIE Code
0 - Successful Registration 0 - Successful Registration
The information in the CIE was sucessfully registered with the The information in the CIE was successfully registered with the
NHS. NHS.
4 - Can't Serve This Address 4 - Can't Serve This Address
An NHS may refuse an NHRP Registration Request attempt for An NHS may refuse an NHRP Registration Request attempt for
administrative reasons (due to policy constraints or routing administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Registration Reply state). If so, the NHS MUST send an NHRP Registration Reply
which contains a NAK code of 4. which contains a NAK code of 4.
5 - Registration Overflow 5 - Registration Overflow
skipping to change at page 26, line 41 skipping to change at page 27, line 24
If a client tries to register a protocol address to NBMA If a client tries to register a protocol address to NBMA
address binding with the uniqueness bit on and the protocol address binding with the uniqueness bit on and the protocol
address already exists in the NHS's cache then if that cache address already exists in the NHS's cache then if that cache
entry also has the uniqueness bit on then this NAK Code is entry also has the uniqueness bit on then this NAK Code is
returned in the CIE in the NHRP Registration Reply. returned in the CIE in the NHRP Registration Reply.
Due to the possible existence of asymmetric routing, an NHRP Due to the possible existence of asymmetric routing, an NHRP
Registration Reply may not be able to merely follow the routed path Registration Reply may not be able to merely follow the routed path
back to the source protocol address specified in the common header of back to the source protocol address specified in the common header of
the NHRP Registration Reply. As a result, there MUST exist a direct the NHRP Registration Reply. As a result, there MUST exist a direct
NBMA level connection between the client and its NHS on which to send NBMA level connection between the NHC and its NHS on which to send
the NHRP Registration Reply before NHRP Registration Reply may be the NHRP Registration Reply before NHRP Registration Reply may be
returned to the client. If such a connection does not exist then the returned to the NHC. If such a connection does not exist then the
NHS must setup such a connection to he client by using the source NHS must setup such a connection to the NHC by using the source NBMA
NBMA information supplied in the common header of the NHRP information supplied in the common header of the NHRP Registration
Registration Request. Request.
5.2.5 NHRP Purge Request 5.2.5 NHRP Purge Request
The NHRP Purge Request packet is sent in order to invalidate cached The NHRP Purge Request packet is sent in order to invalidate cached
information in a station. The NHRP Purge Request packet has a type 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 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 described in Section 5.2.0.1. The message specific meanings of the
fields are as follows: fields are as follows:
Flags - The flags field is coded as follows: Flags - The flags field is coded as follows:
skipping to change at page 27, line 40 skipping to change at page 28, line 24
Code Code
This field is set to 0x00 in NHRP Purge Requests. This field is set to 0x00 in NHRP Purge Requests.
Prefix Length Prefix Length
In the case of NHRP Purge Requests, the Prefix Length specifies In the case of NHRP Purge Requests, the Prefix Length specifies
the equivalence class of addresses which match the first "Prefix the equivalence class of addresses which match the first "Prefix
Length" bit positions of the Client Protocol Address specified in Length" bit positions of the Client Protocol Address specified in
the CIE. All next hop information which contains a protocol the CIE. All next hop information which contains a protocol
address which matches an element of this equivalence class is to address which matches an element of this equivalence class is to
be purged from the receivers cache. If this field is set to 0x00 be purged from the receivers cache.
then this field MUST be ignored and no equivalence information is
assumed.
The Maximum Transmission Unit and Preference fields of the CIE are The Maximum Transmission Unit and Preference fields of the CIE are
coded as zero. The Holding Time should be coded as zero but there 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 may be some utility in supplying a "short" holding time to be
applied to the matching next hop information before that applied to the matching next hop information before that
information would be purged; this usage is for further study. The information would be purged; this usage is for further study. The
Client Protocol Address field and the Cli Proto Len field MUST be Client Protocol Address field and the Cli Proto Len field MUST be
filled in. The Client Protocol Address is filled in with the filled in. The Client Protocol Address is filled in with the
protocol address to be purged from the receiving station's cache 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 while the Cli Proto Len is set the length of the purged client's
skipping to change at page 28, line 19 skipping to change at page 28, line 49
Purge Request may choose to ignore the Client NBMA information if Purge Request may choose to ignore the Client NBMA information if
it is supplied. it is supplied.
An NHRP Purge Request packet is sent from an NHS to a station to 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 cause it to delete previously cached information. This is done when
the information may be no longer valid (typically when the NHS has the information may be no longer valid (typically when the NHS has
previously provided next hop information for a station that is not previously provided next hop information for a station that is not
directly connected to the NBMA subnetwork, and the egress point to directly connected to the NBMA subnetwork, and the egress point to
that station may have changed). that station may have changed).
An NHRP Purge Request packet may also be sent from a client to an NHS An NHRP Purge Request packet may also be sent from an NHC to an NHS
with which the client had previously registered. This allows for a with which the NHC had previously registered. This allows for an NHC
client to invalidate its registration with NHRP before it would to invalidate its registration with NHRP before it would otherwise
otherwise expire via the holding timer. 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 The station sending the NHRP Purge Request MAY periodically
retransmit the NHRP Purge Request until either NHRP Purge Request is retransmit the NHRP Purge Request until either NHRP Purge Request is
acknowledged or until the holding time of the information being acknowledged or until the holding time of the information being
purged has expired. Retransmission strategies for NHRP Purge purged has expired. Retransmission strategies for NHRP Purge
Requests are a local matter. Requests are a local matter.
When a station receives an NHRP Purge Request, it MUST discard any When a station receives an NHRP Purge Request, it MUST discard any
previously cached information that matches the information in the previously cached information that matches the information in the
CIEs. CIEs.
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even 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 if the station does not have a matching cache entry assuming that the
"N" bit is off in the NHRP Purge Request. "N" bit is off in the NHRP Purge Request.
If the station wishes to reestablish communication with the If the station wishes to reestablish communication with the
destination shortly after receiving an NHRP Purge Request, it should destination shortly after receiving an NHRP Purge Request, it should
make an authoritative Next Hop Resolution Request in order to avoid make an authoritative NHRP Resolution Request in order to avoid any
any stale cache entries that might be present in intermediate NHSs stale cache entries that might be present in intermediate NHSs (See
(See section 6.2.2.). It is recommended that authoritative Next Hop section 6.2.2.). It is recommended that authoritative NHRP
Resolution Requests be made for the duration of the holding time of Resolution Requests be made for the duration of the holding time of
the old information. the old information.
5.2.6 NHRP Purge Reply 5.2.6 NHRP Purge Reply
The NHRP Purge Reply packet is sent in order to assure the sender of 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 an NHRP Purge Request that all cached information of the specified
type has been purged from the station sending the reply. The NHRP type has been purged from the station sending the reply. The NHRP
Purge Reply has a type code of 6. Purge Reply has a type code of 6.
skipping to change at page 30, line 8 skipping to change at page 31, line 7
1 - Unrecognized Extension 1 - Unrecognized Extension
When the Compulsory bit of an extension in NHRP packet is set, When the Compulsory bit of an extension in NHRP packet is set,
the NHRP packet cannot be processed unless the extension has the NHRP packet cannot be processed unless the extension has
been processed. The responder MUST return an NHRP Error been processed. The responder MUST return an NHRP Error
Indication of type Unrecognized Extension if it is incapable of Indication of type Unrecognized Extension if it is incapable of
processing the extension. However, if a transit NHS (one which processing the extension. However, if a transit NHS (one which
is not going to generate a reply) detects an unrecognized is not going to generate a reply) detects an unrecognized
extension, it SHALL ignore the extension. extension, it SHALL ignore the extension.
2 - Subnetwork ID Mismatch
This error occurs when the current station receives an NHRP
packet whose NBMA subnetwork identifier matches none of the
locally known identifiers for the NBMA subnetwork on which the
packet is received.
3 - NHRP Loop Detected 3 - NHRP Loop Detected
A Loop Detected error is generated when it is determined that A Loop Detected error is generated when it is determined that
an NHRP packet is being forwarded in a loop. an NHRP packet is being forwarded in a loop.
6 - Protocol Address Unreachable 6 - Protocol Address Unreachable
This error occurs when a packet it moving along the routed path This error occurs when a packet it moving along the routed path
and it reaches a point such that the protocol address of and it reaches a point such that the protocol address of
interest is not reachable. interest is not reachable.
skipping to change at page 30, line 42 skipping to change at page 31, line 34
If the SDU size of the NHRP packet exceeds the MTU size of the If the SDU size of the NHRP packet exceeds the MTU size of the
NBMA network then this error is returned. NBMA network then this error is returned.
9 - Invalid Extension 9 - Invalid Extension
If an NHS finds an extension in a packet which is inappropriate 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 for the packet type, an error is sent back to the sender with
Invalid Extension as the code. Invalid Extension as the code.
10- Invalid Next Hop Resolution Reply Received 10 - Invalid NHRP Resolution Reply Received
If a client receives a Next Hop Resolution Reply for a Next Hop If a client receives a NHRP Resolution Reply for a Next Hop
Resolution Request which it believes it did not make then an Resolution Request which it believes it did not make then an
error packet is sent to the station making the reply with an error packet is sent to the station making the reply with an
error code of Invalid Reply Received. error code of Invalid Reply Received.
11- Authentication Failure 11- Authentication Failure
If a received packet fails an authentication test then this If a received packet fails an authentication test then this
error is returned. error is returned.
14- Hop Count Exceeded 15 - Hop Count Exceeded
The hop count which was specified in the Fixed Header of an The hop count which was specified in the Fixed Header of an
NHRP message has been exceeded. NHRP message has been exceeded.
Error Offset Error Offset
The offset in octets into the NHRP packet, starting at the NHRP The offset in octets into the NHRP packet, starting at the NHRP
Fixed Header, at which the error was detected. Fixed Header, at which the error was detected.
Source NBMA Address Source NBMA Address
The Source NBMA address field is the address of the station which The Source NBMA address field is the address of the station which
skipping to change at page 31, line 49 skipping to change at page 32, line 41
and Source Protocol address fields of a transiting NHRP Error and Source Protocol address fields of a transiting NHRP Error
Indication packet then the NHS will quietly drop the packet and do Indication packet then the NHS will quietly drop the packet and do
nothing (this scenario would occur when the NHRP Error Indication nothing (this scenario would occur when the NHRP Error Indication
packet was itself in a loop). packet was itself in a loop).
Note that no extensions may be added to an NHRP Error Indication. Note that no extensions may be added to an NHRP Error Indication.
5.3 Extensions Part 5.3 Extensions Part
The Extensions Part, if present, carries one or more extensions in The Extensions Part, if present, carries one or more extensions in
{Type, Length, Value} triplets. Extensions are only present in a {Type, Length, Value} triplets.
"reply" if they were present in the corresponding "request";
therefore, minimal NHRP client implementations which do not also act
as an NHS and do not transmit extensions need not be able to receive
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 clients. An implementation that is incapable of
processing extensions SHALL return an NHRP Error Indication of type
Unrecognized Extension when it receives an NHRP packet containing
extensions.
Extensions have the following format: Extensions have the following format:
0 1 2 3 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 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 | |C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 45 skipping to change at page 33, line 34
qualified by the Compulsory bit, but is orthogonal to it. qualified by the Compulsory bit, but is orthogonal to it.
Length Length
The length in octets of the value (not including the Type and The length in octets of the value (not including the Type and
Length fields; a null extension will have only an extension header Length fields; a null extension will have only an extension header
and a length of zero). and a length of zero).
When extensions exist, the extensions list is terminated by the Null When extensions exist, the extensions list is terminated by the Null
TLV, having Type = 0 and Length = 0. TLV, having Type = 0 and Length = 0.
Extensions may occur in any order, but any particular extension type Extensions may occur in any order (see Section 5.3.4 for the
(except for the vendor-private extension) may occur only once in an exception), but any particular extension type may occur only once in
NHRP packet. The vendor-private extension may occur multiple times an NHRP packet with the exception of the Vendor Private extension.
in a packet in order to allow for extensions which do not share the The vendor-private extension may occur multiple times in a packet in
same vendor ID to be represented. 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
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. The Compulsory bit provides for a means to add to the extension set.
If the bit is set, the NHRP message cannot be properly processed by If the bit is set, the NHRP message cannot be properly processed by
the station responding to the message (e.g., the station that would the station responding to the message (e.g., the station that would
issue a Next Hop Resolution Reply in response to a Next Hop issue a NHRP Resolution Reply in response to a NHRP Resolution
Resolution Request) without processing the extension. As a result, Request) without processing the extension. As a result, the
the responder MUST return an NHRP Error Indication of type responder MUST return an NHRP Error Indication of type Unrecognized
Unrecognized Extension. If the Compulsory bit is clear then the Extension. If the Compulsory bit is clear then the extension can be
extension can be safely ignored; however, if an ignored extension is safely ignored; however, if an ignored extension is in a "request"
in a "request" then it MUST be returned, unchanged, in the then it MUST be returned, unchanged, in the corresponding "reply"
corresponding "reply" packet type. packet type.
If a transit NHS (one which is not going to generate a "reply") If a transit NHS (one which is not going to generate a "reply")
detects an unrecognized extension, it SHALL ignore the extension. If detects an unrecognized extension, it SHALL ignore the extension. If
the Compulsory bit is set, the transit NHS MUST NOT cache the the Compulsory bit is set, the transit NHS MUST NOT cache the
information contained in the packet and MUST NOT identify itself as information contained in the packet and MUST NOT identify itself as
an egress router (in the Forward Record or Reverse Record an egress router (in the Forward Record or Reverse Record
extensions). Effectively, this means, if a transit NHS encounters an extensions). Effectively, this means, if a transit NHS encounters an
extension which it cannot process and which has the Compulsory bit extension which it cannot process and which has the Compulsory bit
set then that NHS MUST NOT participate in any way in the protocol set then that NHS MUST NOT participate in any way in the protocol
exchange other than acting as a forwarding agent. exchange other than acting as a forwarding agent.
skipping to change at page 33, line 39 skipping to change at page 34, line 39
5.3.0 The End Of Extensions 5.3.0 The End Of Extensions
Compulsory = 1 Compulsory = 1
Type = 0 Type = 0
Length = 0 Length = 0
When extensions exist, the extensions list is terminated by the End When extensions exist, the extensions list is terminated by the End
Of Extensions/Null TLV. Of Extensions/Null TLV.
5.3.1 Extension with Type 1 not assigned. 5.3.1 Responder Address Extension
5.3.2 NBMA Subnetwork ID Extension
Compulsory = 1
Type = 2
Length = variable
This extension is used to carry one or more identifiers for the NBMA
subnetwork. This can be used as a validity check to ensure that an
NHRP packet does not leave a particular NBMA subnetwork. The
extension is placed in a "request" packet with an ID value of zero.
The first NHS along the routed path fills in the field with the
identifier(s) for the NBMA subnetwork.
Multiple NBMA Subnetwork IDs may be used as a transition mechanism
while NBMA Subnetworks are being split or merged.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA Subnetwork ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Each identifier consists of a 32 bit globally unique value assigned
to the NBMA subnetwork. This value may be chosen from the
internetworking layer address space administered by the operators of
the NBMA subnetwork if such an address can fit into a 32 bit field.
This value is used for identification only, not for routing or any
other purpose.
Each NHS processing a "request" or "reply" SHALL verify these values.
If the value is not zero and none of the values matches the NHS's
NBMA Subnetwork ID, the NHS SHALL return an NHRP Error Indication to
the entity identified in Source Protocol Address if the packet type
is a "request" and to the Destination Protocol Address if the packet
type is a "reply". The error indicated in this case is "Subnetwork
ID Mismatch". The packet is discarded by the station sending the
NHRP Error Indication.
When an NHS is building a "reply" and the NBMA Subnetwork ID
extension is present in the correspond "request" then the NBMA
Subnetwork ID extension SHALL be copied from the "request" to the
"reply".
5.3.3 Responder Address Extension
Compulsory = 1 Compulsory = 1
Type = 3 Type = 3
Length = variable Length = variable
This extension is used to determine the address of the NHRP This extension is used to determine the address of the NHRP
responder; i.e., the entity that generates the appropriate "reply" responder; i.e., the entity that generates the appropriate "reply"
packet for a given "request" packet. In the case of an Next Hop packet for a given "request" packet. In the case of an NHRP
Resolution Request, the station responding may be different (in the Resolution Request, the station responding may be different (in the
case of cached replies) than the system identified in the Next Hop case of cached replies) than the system identified in the Next Hop
field of the Next Hop Resolution Reply. Further, this extension may field of the NHRP Resolution Reply. Further, this extension may aid
aid in detecting loops in the NHRP forwarding path. in detecting loops in the NHRP forwarding path.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res Addr T/L | Res SAddr T/L| Res Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information is considered to be valid. Cached information
SHALL be discarded when the holding time expires.
Res Addr T/L
Type & length of the responder NHS's NBMA address interpreted in
the context of the 'address family number'[6] indicated by ar$afn
(e.g., ar$afn=0x0003 for ATM). When the address length is
specified as 0 no storage is allocated for the address.
Res SAddr T/L This extension uses a single CIE with the extension specific meanings
Type & length of responder NHS's NBMA subaddress interpreted in the of the fields set as follows:
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.
Res Proto Len The Code and Prefix Length fields MUST be set to 0 and ignored.
This field holds the length in octets of responding NHS's Protocol
Address.
Responder NBMA Address Maximum Transmission Unit
This is the NBMA address of the responding NHS. 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.
Responder NBMA SubAddress Holding Time
This is the NBMA subaddress of the responding NHS. 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.
Responder Protocol Address "Client Address" information is actually "Responder Address"
This is the Protocol Address of responding NHS. 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 If a "requester" desires this information, the "requester" SHALL
include this extension with a value of zero. Note that this implies include this extension with a value of zero. Note that this implies
that no storage is allocated for the Holding Time and Type/Length that no storage is allocated for the Holding Time and Type/Length
fields until the "Value" portion of the extension is filled out. fields until the "Value" portion of the extension is filled out.
If an NHS is generating a "reply" packet in response to a "request" If an NHS is generating a "reply" packet in response to a "request"
containing this extension, the NHS SHALL include this extension, containing this extension, the NHS SHALL include this extension,
containing its protocol address in the "reply". If an NHS has more containing its protocol address in the "reply". If an NHS has more
than one protocol address, it SHALL use the same protocol address than one protocol address, it SHALL use the same protocol address
consistently in all of the Responder Address, Forward NHS Record, and consistently in all of the Responder Address, Forward Transit NHS
Reverse NHS Record extensions. The choice of which of several Record, and Reverse Transit NHS Record extensions. The choice of
protocol address to include in this extension is a local matter. which of several protocol address to include in this extension is a
local matter.
If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS If an NHRP Resolution Reply packet being forwarded by an NHS contains
contains a protocol address of that NHS in the Responder Address a protocol address of that NHS in the Responder Address Extension
Extension then that NHS SHALL generate an NHRP Error Indication of then that NHS SHALL generate an NHRP Error Indication of type "NHRP
type "NHRP Loop Detected" and discard the Next Hop Resolution Reply. Loop Detected" and discard the NHRP Resolution Reply.
If an NHRP Next Hop Resolution Reply packet is being returned by an If an NHRP Resolution Reply packet is being returned by an
intermediate NHS based on cached data, it SHALL place its own address intermediate NHS based on cached data, it SHALL place its own address
in this extension (differentiating it from the address in the Next in this extension (differentiating it from the address in the Next
Hop field). Hop field).
5.3.4 NHRP Forward Transit NHS Record Extension 5.3.2 NHRP Forward Transit NHS Record Extension
Compulsory = 1 Compulsory = 1
Type = 4 Type = 4
Length = variable Length = variable
The NHRP Forward Transit NHS record contains a list of transit NHSs The NHRP Forward Transit NHS record contains a list of transit NHSs
through which a "request" has traversed. Each NHS SHALL append to through which a "request" has traversed. Each NHS SHALL append to
the extension a Forward Transit NHS element (as specified below) the extension a Forward Transit NHS element (as specified below)
containing its Protocol address The extension length field and the containing its Protocol address The extension length field and the
ar$chksum fields SHALL be adjusted appropriately. ar$chksum fields SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.3, SHALL NOT update The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension. this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
The Forward Transit NHS element has the following form: This extension uses a single CIE with the extension specific meanings
of the fields set as follows:
0 1 2 3 The Code and Prefix Length fields MUST be set to 0 and ignored.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Transmission Unit
| unused | Holding Time | This field gives the maximum transmission unit preferred by the
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ transit NHS. If this value is 0 then either the default MTU is
| NHS Addr T/L | NHS SAddr T/L| NHS Proto Len | unused | used or the MTU negotiated via signaling is used if such
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ negotiation is possible for the given NBMA.
| NHS NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Holding Time Holding Time
The Holding Time field specifies the number of seconds for which The Holding Time field specifies the number of seconds for which
the NBMA information is considered to be valid. Cached information the NBMA information of the transit NHS is considered to be valid.
SHALL be discarded when the holding time expires. Cached information SHALL be discarded when the holding time
expires.
NHS Addr T/L
Type & length of the transit NHS's NBMA address interpreted in the
context of the 'address family number'[6] indicated by ar$afn
(e.g., ar$afn=0x0003 for ATM). When the address length is
specified as 0 no storage is allocated for the address.
NHS SAddr T/L
Type & length of the transit NHS's NBMA subaddress interpreted in
the context of the 'address family number'[6] indicated by ar$afn
(e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the
subaddress an ATM Forum NSAP address). When an NBMA technology has
no concept of a subaddress the subaddress is always null with a
length of 0. When the address length is specified as 0 no storage
is allocated for the address.
NHS Proto Len
This field holds the length in octets of the transit NHS's Protocol
Address.
NHS NBMA Address
This is the NBMA address of the transit NHS.
NHS NBMA SubAddress
This is the NBMA subaddress of the transit NHS.
NHS Protocol Address "Client Address" information is actually "Forward Transit NHS
This is the Protocol Address of the 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 If a "requester" wishes to obtain this information, it SHALL include
this extension with a length of zero. Note that this implies that no this extension with a length of zero. Note that this implies that no
storage is allocated for the Holding Time and Type/Length fields storage is allocated for the Holding Time and Type/Length fields
until the "Value" portion of the extension is filled out. until the "Value" portion of the extension is filled out.
If an NHS has more than one Protocol address, it SHALL use the same If an NHS has more than one Protocol address, it SHALL use the same
Protocol address consistently in all of the Responder Address, Protocol address consistently in all of the Responder Address,
Forward NHS Record, and Reverse NHS Record extensions. The choice of Forward NHS Record, and Reverse NHS Record extensions. The choice of
which of several Protocol addresses to include in this extension is a which of several Protocol addresses to include in this extension is a
local matter. local matter.
If a "request" that is being forwarded by an NHS contains the If a "request" that is being forwarded by an NHS contains the
Protocol Address of that NHS in one of the Forward Transit NHS Protocol Address of that NHS in one of the Forward Transit NHS
elements then the NHS SHALL generate an NHRP Error Indication of type elements then the NHS SHALL generate an NHRP Error Indication of type
"NHRP Loop Detected" and discard the "request". "NHRP Loop Detected" and discard the "request".
5.3.5 NHRP Reverse Transit NHS Record Extension 5.3.3 NHRP Reverse Transit NHS Record Extension
Compulsory = 1 Compulsory = 1
Type = 5 Type = 5
Length = variable Length = variable
The NHRP Reverse Transit NHS record contains a list of transit NHSs The NHRP Reverse Transit NHS record contains a list of transit NHSs
through which a "reply" has traversed. Each NHS SHALL append a through which a "reply" has traversed. Each NHS SHALL append a
Reverse Transit NHS element (as specified below) containing its Reverse Transit NHS element (as specified below) containing its
Protocol address to this extension. The extension length field and Protocol address to this extension. The extension length field and
ar$chksum SHALL be adjusted appropriately. ar$chksum SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.3, SHALL NOT update The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension. this extension.
In addition, NHSs that are willing to act as egress routers for In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information packets from the source to the destination SHALL include information
about their NBMA Address. about their NBMA Address.
The Reverse Transit NHS element has the following form: This extension uses a single CIE with the extension specific meanings
0 1 2 3 of the fields set as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Holding Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS Addr T/L | NHS SAddr T/L| NHS Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHS Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information is considered to be valid. Cached information
SHALL be discarded when the holding time expires.
NHS Addr T/L
Type & length of the responding NHS's NBMA address interpreted in
the context of the 'address family number'[6] indicated by ar$afn
(e.g., ar$afn=0x0003 for ATM). When the address length is
specified as 0 no storage is allocated for the address.
NHS SAddr T/L
Type & length of the responding NHS's NBMA subaddress interpreted
in the context of the 'address family number'[6] indicated by
ar$afn (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and
the subaddress an ATM Forum NSAP address). When an NBMA technology
has no concept of a subaddress the subaddress is always null with a
length of 0. When the address length is specified as 0 no storage
is allocated for the address.
NHS Proto Len The Code and Prefix Length fields MUST be set to 0 and ignored.
This field holds the length in octets of the transit NHS's Protocol
Address.
NHS NBMA Address Maximum Transmission Unit
This is the NBMA address of the transit NHS. 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.
NHS NBMA SubAddress Holding Time
This is the NBMA subaddress of the transit NHS. 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.
NHS Protocol Address "Client Address" information is actually "Reverse Transit NHS
This is the Protocol Address of the 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 If a "requester" wishes to obtain this information, it SHALL include
this extension with a length of zero. Note that this implies that no this extension with a length of zero. Note that this implies that no
storage is allocated for the Holding Time and Type/Length fields storage is allocated for the Holding Time and Type/Length fields
until the "Value" portion of the extension is filled out. until the "Value" portion of the extension is filled out.
If an NHS has more than one Protocol address, it SHALL use the same If an NHS has more than one Protocol address, it SHALL use the same
Protocol address consistently in all of the Responder Address, Protocol address consistently in all of the Responder Address,
Forward NHS Record, and Reverse NHS Record extensions. The choice of Forward NHS Record, and Reverse NHS Record extensions. The choice of
which of several Protocol addresses to include in this extension is a which of several Protocol addresses to include in this extension is a
local matter. local matter.
If a "reply" that is being forwarded by an NHS contains the Protocol 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 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 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
Detected" and discard the "reply". Detected" and discard the "reply".
Note that this information may be cached at intermediate NHSs; if Note that this information may be cached at intermediate NHSs; if
so, the cached value SHALL be used when generating a reply. so, the cached value SHALL be used when generating a reply.
5.3.6 NHRP QoS Extension 5.3.4 NHRP Authentication Extension
Compulsory = 0
Type = 6
Length = variable
The NHRP QoS Extension is carried in Next Hop Resolution Request
packets to indicate the desired QoS of the path to the indicated
destination. This information may be used to help select the
appropriate NBMA Next Hop.
It may also be carried in NHRP Register Request packets to indicate
the QoS to which the registration applies.
The syntax and semantics of this extension are TBD; alignment with
resource reservation may be useful.
5.3.7 NHRP Authentication Extension
Compulsory = 1 Compulsory = 1
Type = 7 Type = 7
Length = variable Length = variable
The NHRP Authentication Extension is carried in NHRP packets to The NHRP Authentication Extension is carried in NHRP packets to
convey authentication information between NHRP speakers. The convey authentication information between NHRP speakers. The
Authentication Extension may be included in any NHRP "request" or Authentication Extension may be included in any NHRP "request" or
"reply". "reply" only.
Except in the case of an NHRP Registration Request/Reply Except in the case of an NHRP Registration Request/Reply
Authentication is done pairwise on an NHRP hop-by-hop basis; i.e., Authentication is done pairwise on an NHRP hop-by-hop basis; i.e.,
the authentication extension is regenerated at each hop. In the case the authentication extension is regenerated at each hop. In the case
of an NHRP Registration Request/Reply, the Authentication is checked of an NHRP Registration Request/Reply, the Authentication is checked
on an end-to-end basis rather than hop-by-hop. If a received packet on an end-to-end basis rather than hop-by-hop. If a received packet
fails the authentication test, the station SHALL generate an Error fails the authentication test, the station SHALL generate an Error
Indication of type "Authentication Failure" and discard the packet. Indication of type "Authentication Failure" and discard the packet.
Note that one possible authentication failure is the lack of an Note that one possible authentication failure is the lack of an
Authentication Extension; the presence or absence of the Authentication Extension; the presence or absence of the
skipping to change at page 41, line 33 skipping to change at page 39, line 22
The Authentication Data field contains the type-specific The Authentication Data field contains the type-specific
authentication information. authentication information.
In the case of Cleartext Password Authentication, the Authentication In the case of Cleartext Password Authentication, the Authentication
Data consists of a variable length password. Data consists of a variable length password.
In the case of Keyed MD5 Authentication, the Authentication Data In the case of Keyed MD5 Authentication, the Authentication Data
contains the 16 byte MD5 digest of the entire NHRP packet, including contains the 16 byte MD5 digest of the entire NHRP packet, including
the encapsulated protocol's header, with the authentication key the encapsulated protocol's header, with the authentication key
appended to the end of the packet. The authentication key is not appended to the end of the packet. The authentication key is not
transmitted with the packet. transmitted with the packet. The MD5 digest covers only the
following fields of the NHRP packet: fixed part (with hop count,
packet size and checksum being set to zero), mandatory part,
Responder Address extension, and authentication extension. Note that
when MD5 is used, there is an explicit ordering of the extensions
such that: if the Responder Address extension exists then it MUST be
the first extension in the packet and the Authentication Extension
MUST be the second extension otherwise the Authentication Extension
MUST be the first extension in the packet.
Distribution of authentication keys is outside the scope of this Distribution of authentication keys is outside the scope of this
document. document.
5.3.8 NHRP Vendor-Private Extension 5.3.5 NHRP Vendor-Private Extension
Compulsory = 0 Compulsory = 0
Type = 8 Type = 8
Length = variable Length = variable
The NHRP Vendor-Private Extension is carried in NHRP packets to The NHRP Vendor-Private Extension is carried in NHRP packets to
convey vendor-private information or NHRP extensions between NHRP convey vendor-private information or NHRP extensions between NHRP
speakers. speakers.
0 1 2 3 0 1 2 3
skipping to change at page 42, line 18 skipping to change at page 40, line 17
The remaining octets after the Vendor ID in the payload are The remaining octets after the Vendor ID in the payload are
vendor-dependent data. vendor-dependent data.
This extension may be added to any "request" or "reply" packet and it 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 is the only extension that may be included multiple times. If the
receiver does not handle this extension, or does not match the Vendor receiver does not handle this extension, or does not match the Vendor
ID in the extension then the extension may be completely ignored by ID in the extension then the extension may be completely ignored by
the receiver. If a Vendor Private Extension is included in a the receiver. If a Vendor Private Extension is included in a
"request" then is must be copied in the corresponding "reply". "request" then is must be copied in the corresponding "reply".
5.3.9 Extension with Type 9 not assigned.
6. Protocol Operation 6. Protocol Operation
In this section, we discuss certain operational considerations of In this section, we discuss certain operational considerations of
NHRP. NHRP.
6.1 Router-to-Router Operation 6.1 Router-to-Router Operation
In practice, the initiating and responding stations may be either In practice, the initiating and responding stations may be either
hosts or routers. However, there is a possibility under certain hosts or routers. However, there is a possibility under certain
conditions that a stable routing loop may occur if NHRP is used conditions that a stable routing loop may occur if NHRP is used
skipping to change at page 43, line 9 skipping to change at page 41, line 9
6.2 Cache Management Issues 6.2 Cache Management Issues
The management of NHRP caches in the source station, the NHS serving The management of NHRP caches in the source station, the NHS serving
the destination, and any intermediate NHSs is dependent on a number the destination, and any intermediate NHSs is dependent on a number
of factors. of factors.
6.2.1 Caching Requirements 6.2.1 Caching Requirements
Source Stations Source Stations
Source stations MUST cache all received Next Hop Resolution Replies Source stations MUST cache all received NHRP Resolution Replies that
that they are actively using. They also must cache "incomplete" they are actively using. They also must cache "incomplete" entries,
entries, i.e., those for which a Next Hop Resolution Request has i.e., those for which a NHRP Resolution Request has been sent but
been sent but which a Next Hop Resolution Reply has not been which a NHRP Resolution Reply has not been received. This is
received. This is necessary in order to preserve the Request ID necessary in order to preserve the Request ID for retries, and
for retries, and provides the state necessary to avoid triggering provides the state necessary to avoid triggering NHRP Resolution
Next Hop Resolution Requests for every data packet sent to the Requests for every data packet sent to the destination.
destination.
Source stations MUST purge expired information from their caches. Source stations MUST purge expired information from their caches.
Source stations MUST purge the appropriate cached information upon Source stations MUST purge the appropriate cached information upon
receipt of an NHRP Purge Request packet. receipt of an NHRP Purge Request packet.
When a station has a co-resident client and NHS, the station may When a station has a co-resident client and NHS, the station may
reply to Next Hop Resolution Requests with information which the reply to NHRP Resolution Requests with information which the station
station cached as a result of the station making its own Next Hop cached as a result of the station making its own NHRP Resolution
Resolution Requests and receiving its own Next Hop Resolution Requests and receiving its own NHRP Resolution Replies as long as the
Replies as long as the station follows the rules for Transit NHSs station follows the rules for Transit NHSs as seen below.
as seen below.
Serving NHSs Serving NHSs
The NHS serving the destination (the one which responds The NHS serving the destination (the one which responds
authoritatively to Next Hop Resolution Requests) SHOULD cache authoritatively to NHRP Resolution Requests) SHOULD cache information
information about all Next Hop Resolution Requests to which it has about all NHRP Resolution Requests to which it has responded if the
responded if the information in the Next Hop Resolution Reply has information in the NHRP Resolution Reply has the possibility of
the possibility of changing during its lifetime (so that an NHRP changing during its lifetime (so that an NHRP Purge Request packet
Purge Request packet can be sent). The NBMA information provided can be sent). The NBMA information provided by the source station in
by the source station in the Next Hop Resolution Request may be the NHRP Resolution Request may be cached for the duration of its
cached for the duration of its holding time. This information is holding time. This information is considered to be stable, since it
considered to be stable, since it identifies a station directly identifies a station directly attached to the NBMA subnetwork. An
attached to the NBMA subnetwork. An example of unstable example of unstable information is NBMA information derived from a
information is NBMA information derived from a routing table, where routing table, where that routing table information has not been
that routing table information has not been guaranteed to be stable guaranteed to be stable through administrative means.
through administrative means.
Transit NHSs Transit NHSs
A Transit NHS (lying along the NHRP path between the source station A Transit NHS (lying along the NHRP path between the source station
and the responding NHS) may cache information contained in Next Hop and the responding NHS) may cache information contained in NHRP
Resolution Request packets that it forwards. A Transit NHS may Resolution Request packets that it forwards. A Transit NHS may cache
cache information contained in Next Hop Resolution Reply packets information contained in NHRP Resolution Reply packets that it
that it forwards only if that Next Hop Resolution Reply has the forwards only if that NHRP Resolution Reply has the Stable (B) bit
Stable (B) bit set. It MUST discard any cached information whose set. It MUST discard any cached information whose holding time has
holding time has expired. It may return cached information in expired. It may return cached information in response to non-
response to non-authoritative Next Hop Resolution Requests only. authoritative NHRP Resolution Requests only.
6.2.2 Dynamics of Cached Information 6.2.2 Dynamics of Cached Information
NBMA-Connected Destinations NBMA-Connected Destinations
NHRP's most basic function is that of simple NBMA address NHRP's most basic function is that of simple NBMA address
resolution of stations directly attached to the NBMA subnetwork. resolution of stations directly attached to the NBMA subnetwork.
These mappings are typically very static, and appropriately chosen These mappings are typically very static, and appropriately chosen
holding times will minimize problems in the event that the NBMA holding times will minimize problems in the event that the NBMA
address of a station must be changed. Stale information will cause address of a station must be changed. Stale information will cause
a loss of connectivity, which may be used to trigger an a loss of connectivity, which may be used to trigger an
authoritative Next Hop Resolution Request and bypass the old data. authoritative NHRP Resolution Request and bypass the old data. In
In the worst case, connectivity will fail until the cache entry the worst case, connectivity will fail until the cache entry times
times out. out.
This applies equally to information marked in Next Hop Resolution This applies equally to information marked in NHRP Resolution
Replies as being "stable" (via the "B" bit). Replies as being "stable" (via the "B" bit).
This also applies equally well to source stations that are routers This also applies equally well to source stations that are routers
as well as those which are hosts. as well as those which are hosts.
Note that the information carried in the Next Hop Resolution Note that the information carried in the NHRP Resolution Request
Request packet is always considered "stable" because it represents packet is always considered "stable" because it represents a
a station that is directly connected to the NBMA subnetwork. station that is directly connected to the NBMA subnetwork.
Destinations Off of the NBMA Subnetwork Destinations Off of the NBMA Subnetwork
If the source of a Next Hop Resolution Request is a host and the If the source of a NHRP Resolution Request is a host and the
destination is not directly attached to the NBMA subnetwork, and destination is not directly attached to the NBMA subnetwork, and
the route to that destination is not considered to be "stable," the the route to that destination is not considered to be "stable," the
destination mapping may be very dynamic (except in the case of a destination mapping may be very dynamic (except in the case of a
subnetwork where each destination is only singly homed to the NBMA subnetwork where each destination is only singly homed to the NBMA
subnetwork). As such the cached information may very likely become subnetwork). As such the cached information may very likely become
stale. The consequence of stale information in this case will be a stale. The consequence of stale information in this case will be a
suboptimal path (unless the internetwork has partitioned or some suboptimal path (unless the internetwork has partitioned or some
other routing failure has occurred). other routing failure has occurred).
6.3 Use of the Prefix Length field of a CIE 6.3 Use of the Prefix Length field of a CIE
skipping to change at page 45, line 10 skipping to change at page 43, line 8
it). Assuming that the routers on the NBMA subnetwork are exchanging it). Assuming that the routers on the NBMA subnetwork are exchanging
routing information, it should not be possible for an NHS to create a 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 black hole by advertising too large of a set of destinations, but
suboptimal routing (e.g., extra internetwork layer hops through the suboptimal routing (e.g., extra internetwork layer hops through the
NBMA) can result. To avoid this situation an NHS that wants to send NBMA) can result. To avoid this situation an NHS that wants to send
the Prefix Length MUST obey the following rule: the Prefix Length MUST obey the following rule:
The NHS examines the Network Layer Reachability Information (NLRI) The NHS examines the Network Layer Reachability Information (NLRI)
associated with the route that the NHS would use to forward towards associated with the route that the NHS would use to forward towards
the destination (as specified by the Destination internetwork layer the destination (as specified by the Destination internetwork layer
address in the Next Hop Resolution Request), and extracts from this address in the NHRP Resolution Request), and extracts from this
NLRI the shortest address prefix such that: (a) the Destination NLRI the shortest address prefix such that: (a) the Destination
internetwork layer address (from the Next Hop Resolution Request) internetwork layer address (from the NHRP Resolution Request) is
is covered by the prefix, (b) the NHS does not have any routes with covered by the prefix, (b) the NHS does not have any routes with
NLRI that forms a subset of what is covered by the prefix. The NLRI that forms a subset of what is covered by the prefix. The
prefix may then be used in the CIE. prefix may then be used in the CIE.
The Prefix Length field of the CIE should be used with restraint, in The Prefix Length field of the CIE should be used with restraint, in
order to avoid NHRP stations choosing suboptimal transit paths when order to avoid NHRP stations choosing suboptimal transit paths when
overlapping prefixes are available. This document specifies the use overlapping prefixes are available. This document specifies the use
of the prefix length only when all the destinations covered by the of the prefix length only when all the destinations covered by the
prefix are "stable". That is, either: prefix are "stable". That is, either:
(a) All destinations covered by the prefix are on the NBMA network, or (a) All destinations covered by the prefix are on the NBMA network, or
skipping to change at page 45, line 35 skipping to change at page 43, line 33
(b) All destinations covered by the prefix are directly attached to (b) All destinations covered by the prefix are directly attached to
the NHRP responding station. the NHRP responding station.
Use of the Prefix Length field of the CIE in other circumstances is Use of the Prefix Length field of the CIE in other circumstances is
outside the scope of this document. outside the scope of this document.
6.4 Domino Effect 6.4 Domino Effect
One could easily imagine a situation where a router, acting as an One could easily imagine a situation where a router, acting as an
ingress station to the NBMA subnetwork, receives a data packet, such ingress station to the NBMA subnetwork, receives a data packet, such
that this packet triggers an Next Hop Resolution Request. If the that this packet triggers an NHRP Resolution Request. If the router
router forwards this data packet without waiting for an NHRP transit forwards this data packet without waiting for an NHRP transit path to
path to be established, then when the next router along the path be established, then when the next router along the path receives the
receives the packet, the next router may do exactly the same - packet, the next router may do exactly the same - originate its own
originate its own Next Hop Resolution Request (as well as forward the NHRP Resolution Request (as well as forward the packet). In fact
packet). In fact such a data packet may trigger Next Hop Resolution such a data packet may trigger NHRP Resolution Request generation at
Request generation at every router along the path through an NBMA every router along the path through an NBMA subnetwork. We refer to
subnetwork. We refer to this phenomena as the NHRP "domino" effect. this phenomena as the NHRP "domino" effect.
The NHRP domino effect is clearly undesirable. At best it may result The NHRP domino effect is clearly undesirable. At best it may result
in excessive NHRP traffic. At worst it may result in an excessive in excessive NHRP traffic. At worst it may result in an excessive
number of virtual circuits being established unnecessarily. number of virtual circuits being established unnecessarily.
Therefore, it is important to take certain measures to avoid or Therefore, it is important to take certain measures to avoid or
suppress this behavior. NHRP implementations for NHSs MUST provide a suppress this behavior. NHRP implementations for NHSs MUST provide a
mechanism to address this problem. One possible strategy to address mechanism to address this problem. One possible strategy to address
this problem would be to configure a router in such a way that Next this problem would be to configure a router in such a way that NHRP
Hop Resolution Request generation by the router would be driven only Resolution Request generation by the router would be driven only by
by the traffic the router receives over its non-NBMA interfaces the traffic the router receives over its non-NBMA interfaces
(interfaces that are not attached to an NBMA subnetwork). Traffic (interfaces that are not attached to an NBMA subnetwork). Traffic
received by the router over its NBMA-attached interfaces would not received by the router over its NBMA-attached interfaces would not
trigger NHRP Next Hop Resolution Requests. Such a router avoids the trigger NHRP NHRP Resolution Requests. Such a router avoids the NHRP
NHRP domino effect through administrative means. domino effect through administrative means.
7. NHRP over Legacy BMA Networks 7. NHRP over Legacy BMA Networks
There would appear to be no significant impediment to running NHRP There would appear to be no significant impediment to running NHRP
over legacy broadcast subnetworks. There may be issues around over legacy broadcast subnetworks. There may be issues around
running NHRP across multiple subnetworks. Running NHRP on broadcast running NHRP across multiple subnetworks. Running NHRP on broadcast
media has some interesting possibilities; especially when setting up media has some interesting possibilities; especially when setting up
a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both 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 end stations are legacy attached. This use for NHRP requires further
research. research.
8. Security Considerations 8. Security Considerations
As in any routing protocol, there are a number of potential security As in any resolution protocol, there are a number of potential
attacks possible. Plausible examples include denial-of-service security attacks possible. Plausible examples include denial-of-
attacks, and masquerade attacks using register and purge packets. service attacks, and masquerade attacks using register and purge
The use of authentication on all packets is recommended to avoid such packets. The use of authentication on all packets is recommended to
attacks. avoid such attacks.
The authentication schemes described in this document are intended to The authentication schemes described in this document are intended to
allow the receiver of a packet to validate the identity of the allow the receiver of a packet to validate the identity of the
sender; they do not provide privacy or protection against replay sender; they do not provide privacy or protection against replay
attacks. attacks.
Detailed security analysis of this protocol is for further study. Detailed security analysis of this protocol is for further study.
9. Discussion 9. Discussion
The result of an Next Hop Resolution Request depends on how routing The result of an NHRP Resolution Request depends on how routing is
is configured among the NHSs of an NBMA subnetwork. If the configured among the NHSs of an NBMA subnetwork. If the destination
destination station is directly connected to the NBMA subnetwork and station is directly connected to the NBMA subnetwork and the the
the the routed path to it lies entirely within the NBMA subnetwork, routed path to it lies entirely within the NBMA subnetwork, the NHRP
the Next Hop Resolution Replies always return the NBMA address of the Resolution Replies always return the NBMA address of the destination
destination station itself rather than the NBMA address of some station itself rather than the NBMA address of some egress router.
egress router. On the other hand, if the routed path exits the NBMA On the other hand, if the routed path exits the NBMA subnetwork, NHRP
subnetwork, NHRP will be unable to resolve the NBMA address of the will be unable to resolve the NBMA address of the destination, but
destination, but rather will return the address of the egress router. rather will return the address of the egress router. For
For destinations outside the NBMA subnetwork, egress routers and destinations outside the NBMA subnetwork, egress routers and routers
routers in the other subnetworks should exchange routing information in the other subnetworks should exchange routing information so that
so that the optimal egress router may be found. the optimal egress router may be found.
In addition to NHSs, an NBMA station could also be associated with In addition to NHSs, an NBMA station could also be associated with
one or more regular routers that could act as "connectionless one or more regular routers that could act as "connectionless
servers" for the station. The station could then choose to resolve servers" for the station. The station could then choose to resolve
the NBMA next hop or just send the packets to one of its the NBMA next hop or just send the packets to one of its
connectionless servers. The latter option may be desirable if connectionless servers. The latter option may be desirable if
communication with the destination is short-lived and/or doesn't communication with the destination is short-lived and/or doesn't
require much network resources. The connectionless servers could, of require much network resources. The connectionless servers could, of
course, be physically integrated in the NHSs by augmenting them with course, be physically integrated in the NHSs by augmenting them with
internetwork layer switching functionality. internetwork layer switching functionality.
skipping to change at page 47, line 42 skipping to change at page 45, line 39
[7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen,
RFC1483. RFC1483.
[8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode,
A. Malis, D. Robinson, and R. Ullmann, RFC1356. A. Malis, D. Robinson, and R. Ullmann, RFC1356.
[9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and
A. Malis, RFC1490. A. Malis, RFC1490.
[10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks,
Yakov Rekhter, Dilip Kandlur, RFCxxxx. Yakov Rekhter, Dilip Kandlur, RFC1937.
Acknowledgments Acknowledgments
We would like to thank Juha Heinenan of Telecom Finland and Ramesh We would like to thank Juha Heinenan of Telecom Finland and Ramesh
Govidan of ISI for their work on NBMA ARP and the original NHRP 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 draft, which served as the basis for this work. Russell Gardo of
IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern
of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of
cisco, and Grenville Armitage of Bellcore should also be acknowledged cisco, and Grenville Armitage of Bellcore should also be acknowledged
for comments and suggestions that improved this work substantially. for comments and suggestions that improved this work substantially.
skipping to change at page 48, line 18 skipping to change at page 46, line 16
the IETF, whose review and discussion of this document have been the IETF, whose review and discussion of this document have been
invaluable. invaluable.
Authors' Addresses Authors' Addresses
James V. Luciani Dave Katz James V. Luciani Dave Katz
Bay Networks cisco Systems Bay Networks cisco Systems
3 Federal Street 170 W. Tasman Dr. 3 Federal Street 170 W. Tasman Dr.
Mail Stop: BL3-04 San Jose, CA 95134 USA Mail Stop: BL3-04 San Jose, CA 95134 USA
Billerica, MA 01821 Phone: +1 408 526 8284 Billerica, MA 01821 Phone: +1 408 526 8284
Phone: +1 508 439 4737 Email: dkatz@cisco.com Phone: +1 508 439 4734 Email: dkatz@cisco.com
Email: luciani@baynetworks.com Email: luciani@baynetworks.com
David Piscitello Bruce Cole David Piscitello Bruce Cole
Core Competence cisco Systems Core Competence cisco Systems
1620 Tuckerstown Road 170 W. Tasman Dr. 1620 Tuckerstown Road 170 W. Tasman Dr.
Dresher, PA 19025 USA San Jose, CA 95134 USA Dresher, PA 19025 USA San Jose, CA 95134 USA
Phone: +1 215 830 0692Phone: Phone: +1 408 526 4000 Phone: +1 215 830 0692 Phone: +1 408 526 4000
Email: dave@corecom.comEmail: Email: bcole@cisco.com Email: dave@corecom.com Email: bcole@cisco.com
 End of changes. 124 change blocks. 
631 lines changed or deleted 543 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/