The Destination Protocol Address in the common header of the
Mandatory Part of this message contains the protocol address of the
station for which resolution is desired. An NHC MUST send the NHRP
Resolution Request directly to one of its serving NHSs (see Section 3
for more information).
5.2.2 NHRP Resolution Reply
The NHRP Resolution Reply packet has a Type code of 2. CIEs
correspond to Next Hop Entries in an NHS's cache which match the
criteria in the NHRP Resolution Request. Its mandatory part is coded
as described in Section 5.2.0.1. The message specific meanings of
the fields are as follows:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q|A|D|U|S| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Copied from the NHRP Resolution Request. Set if the NHRP
Resolution Requester is a router; clear if it is a host.
A
Set if the next hop CIE in the NHRP Resolution Reply is
authoritative; clear if the NHRP Resolution Reply is non-
authoritative.
When an NHS receives a NHRP Resolution Request for authoritative
information for which it is the authoritative source, it MUST
respond with a NHRP Resolution Reply containing all and only
those next hop CIEs which are contained in the NHS's cache which
both match the criteria of the NHRP Resolution Request and are
authoritative cache entries. An NHS is an authoritative source
for a NHRP Resolution Request if the information in the NHS's
cache matches the NHRP Resolution Request criteria and that
information was obtained through a NHRP Registration Request or
through synchronization with an NHS which obtained this
information through a NHRP Registration Request. An
authoritative cache entry is one which is obtained through a NHRP
Registration Request or through synchronization with an NHS which
obtained this information through a NHRP Registration Request.
An NHS obtains non-authoritative CIEs through promiscuous
listening to NHRP packets other than NHRP Registrations which are
directed at it. A NHRP Resolution Request which indicates a
request for non-authoritative information should cause a NHRP
Resolution Reply which contains all entries in the replying NHS's
cache (i.e., both authoritative and non-authoritative) which
match the criteria specified in the request.
D
Set if the association between destination and the associate next
hop information included in all CIEs of the NHRP Resolution Reply
is guaranteed to be stable for the lifetime of the information
(the holding time). This is the case if the Next Hop protocol
address in a CIE identifies the destination (though it may be
different in value than the Destination address if the
destination system has multiple addresses) or if the destination
is not connected directly to the NBMA subnetwork but the egress
router to that destination is guaranteed to be stable (such as
when the destination is immediately adjacent to the egress router
through a non-NBMA interface).
U
This is the Uniqueness bit. See the NHRP Resolution Request
section above for details. When this bit is set, only one CIE is
included since only one unique binding should exist in an NHS's
cache.
S
Copied from NHRP Resolution Request message.
One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
contains NHRP next hop information which the responding NHS has
cached and which matches the parameters specified in the NHRP
Resolution Request. If no match is found by the NHS issuing the NHRP
Resolution Reply then a single CIE is enclosed with the a CIE Code
set appropriately (see below) and all other fields MUST be ignored
and SHOULD be set to 0. In order to facilitate the use of NHRP by
minimal client implementations, the first CIE MUST contain the next
hop with the highest preference value so that such an implementation
need parse only a single CIE.
Code
If this field is set to zero then this packet contains a
positively acknowledged NHRP Resolution Reply. If this field
contains any other value then this message contains an NHRP
Resolution Reply NAK which means that an appropriate
internetworking layer to NBMA address binding was not available
in the responding NHS's cache. If NHRP Resolution Reply contains
a Client Information Entry with a NAK Code other than 0 then it
MUST NOT contain any other CIE. Currently defined NAK Codes are
as follows:
4 - Administratively Prohibited
An NHS may refuse an NHRP Resolution Request attempt for
administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Resolution Reply
which contains a NAK code of 4.
5 - Insufficient Resources
If an NHS cannot serve a station due to a lack of resources
(e.g., can't store sufficient information to send a purge if
routing changes), the NHS MUST reply with a NAKed NHRP
Resolution Reply which contains a NAK code of 5.
12 - No Internetworking Layer Address to NBMA Address Binding
Exists
This code states that there were absolutely no internetworking
layer address to NBMA address bindings found in the responding
NHS's cache.
13 - Binding Exists But Is Not Unique
This code states that there were one or more internetworking
layer address to NBMA address bindings found in the responding
NHS's cache, however none of them had the uniqueness bit set.
Prefix Length
In the case of NHRP Resolution Reply, the Prefix Length specifies
the equivalence class of addresses which match the first "Prefix
Length" bit positions of the Destination Protocol Address.
Holding Time
The Holding Time specified in a CIE of an NHRP Resolution Reply
is the amount of time remaining before the expiration of the
client information which is cached at the replying NHS. It is
not the value which was registered by the client.
The remainder of the fields for the CIE for each next hop are
filled out as they were defined when the next hop was registered
with the responding NHS (or one of the responding NHS's
synchronized servers) via the NHRP Registration Request.
Load-splitting may be performed when more than one Client Information
Entry is returned to a requester when equal preference values are
specified. Also, the alternative addresses may be used in case of
connectivity failure in the NBMA subnetwork (such as a failed call
attempt in connection-oriented NBMA subnetworks).
Any extensions present in the NHRP Resolution Request packet MUST be
present in the NHRP Resolution Reply even if the extension is non-
Compulsory.
If an unsolicited NHRP Resolution Reply packet is received, an Error
Indication of type Invalid NHRP Resolution Reply Received SHOULD be
sent in response.
When an NHS that serves a given NHC receives an NHRP Resolution Reply
destined for that NHC then the NHS must MUST send the NHRP Resolution
Reply directly to the NHC (see Section 3).
5.2.3 NHRP Registration Request
The NHRP Registration Request is sent from a station to an NHS to
notify the NHS of the station's NBMA information. It has a Type code
of 3. Each CIE corresponds to Next Hop information which is to be
cached at an NHS. The mandatory part of an NHRP Registration Request
is coded as described in Section 5.2.0.1. The message specific
meanings of the fields are as follows:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U
This is the Uniqueness bit. When set in an NHRP Registration
Request, this bit indicates that the registration of the protocol
address is unique within the confines of the set of synchronized
NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC
cache. Any attempt to register a binding between the protocol
address and an NBMA address when this bit is set MUST be rejected
with a Code of "14 - Unique Internetworking Layer Address Already
Registered" if the replying NHS already has a cache entry for the
protocol address and the cache entry has the "uniqueness" bit
set. A registration of a CIE's information is rejected when the
CIE is returned with the Code field set to anything other than
0x00. See the description of the uniqueness bit in NHRP
Resolution Request section above for further details. When this
bit is set only, only one CIE MAY be included in the NHRP
Registration Request.
Request ID
The request ID has the same meaning as described in Section
5.2.0.1. However, the request ID for NHRP Registrations which is
maintained at each client MUST be kept in non-volatile memory so
that when a client crashes and reregisters there will be no
inconsistency in the NHS's database. In order to reduce the
overhead associated with updating non-volatile memory, the actual
updating need not be done with every increment of the Request ID
but could be done, for example, every 50 or 100 increments. In
this scenario, when a client crashes and reregisters it knows to
add 100 to the value of the Request ID in the non-volatile memory
before using the Request ID for subsequent registrations.
One or more CIEs are specified in the NHRP Registration Request.
Each CIE contains next hop information which a client is attempting
to register with its servers. Generally, all fields in CIEs enclosed
in NHRP Registration Requests are coded as described in Section
5.2.0.1. However, if a station is only registering itself with the
NHRP Registration Request then it MAY code the Cli Addr T/L, Cli
SAddr T/L, and Cli Proto Len as zero which signifies that the client
address information is to be taken from the source information in the
common header (see Section 5.2.0.1). Below, further clarification is
given for some fields in a CIE in the context of a NHRP Registration
Request.
Code
This field is set to 0x00 in NHRP Registration Requests.
Prefix Length
This field may be used in a NHRP Registration Request to register
equivalence information for the Client Protocol Address specified
in the CIE of an NHRP Registration Request In the case of NHRP
Registration Request, the Prefix Length specifies the equivalence
class of addresses which match the first "Prefix Length" bit
positions of the Client Protocol Address. If the "U" bit is set
in the common header then this field MUST be set to 0xFF.
The NHRP Registration Request is used to register an NHC's NHRP
information with its NHSs. If an NHC is configured with the protocol
address of a serving NHS then the NHC may place the NHS's protocol
address in the Destination Protocol Address field of the NHRP
Registration Request common header otherwise the NHC must place its
own protocol address in the Destination Protocol Address field.
When an NHS receives an NHRP Registration Request which has the
Destination Protocol Address field set to an address which belongs to
a LIS/LAG for which the NHS is serving then if the Destination
Protocol Address field is equal to the Source Protocol Address field
(which would happen if the NHC put its protocol address in the
Destination Protocol Address) or the Destination Protocol Address
field is equal to the protocol address of the NHS then the NHS
processes the NHRP Registration Request after doing appropriate error
checking (including any applicable policy checking).
When an NHS receives an NHRP Registration Request which has the
Destination Protocol Address field set to an address which does not
belong to a LIS/LAG for which the NHS is serving then the NHS
forwards the packet down the routed path toward the appropriate
LIS/LAG.
When an NHS receives an NHRP Registration Request which has the
Destination Protocol Address field set to an address which belongs to
a LIS/LAG for which the NHS is serving then if the Destination
Protocol Address field does not equal the Source Protocol Address
field and the Destination Protocol Address field does not equal the
protocol address of the NHS then the NHS forwards the message to the
appropriate NHS within the LIS/LAG as specified by Destination
Protocol Address field.
It is possible that a misconfigured station will attempt to register
with the wrong NHS (i.e., one that cannot serve it due to policy
constraints or routing state). If this is the case, the NHS MUST
reply with a NAK-ed Registration Reply of type Can't Serve This
Address.
If an NHS cannot serve a station due to a lack of resources, the NHS
MUST reply with a NAK-ed Registration Reply of type Registration
Overflow.
In order to keep the registration entry from being discarded, the
station MUST re-send the NHRP Registration Request packet often
enough to refresh the registration, even in the face of occasional
packet loss. It is recommended that the NHRP Registration Request
packet be sent at an interval equal to one-third of the Holding Time
specified therein.
5.2.4 NHRP Registration Reply
The NHRP Registration Reply is sent by an NHS to a client in response
to that client's NHRP Registration Request. If the Code field of a
CIE in the NHRP Registration Reply has anything other than zero in it
then the NHRP Registration Reply is a NAK otherwise the reply is an
ACK. The NHRP Registration Reply has a Type code of 4.
An NHRP Registration Reply is formed from an NHRP Registration
Request by changing the type code to 4, updating the CIE Code field,
and filling in the appropriate extensions if they exist. The message
specific meanings of the fields are as follows:
Attempts to register the information in the CIEs of an NHRP
Registration Request may fail for various reasons. If this is the
case then each failed attempt to register the information in a CIE of
an NHRP Registration Request is logged in the associated NHRP
Registration Reply by setting the CIE Code field to the appropriate
error code as shown below:
CIE Code
0 - Successful Registration
The information in the CIE was successfully registered with the
NHS.
4 - Administratively Prohibited
An NHS may refuse an NHRP Registration Request attempt for
administrative reasons (due to policy constraints or routing
state). If so, the NHS MUST send an NHRP Registration Reply
which contains a NAK code of 4.
5 - Insufficient Resources
If an NHS cannot serve a station due to a lack of resources,
the NHS MUST reply with a NAKed NHRP Registration Reply which
contains a NAK code of 5.
14 - Unique Internetworking Layer Address Already Registered
If a client tries to register a protocol address to NBMA
address binding with the uniqueness bit on and the protocol
address already exists in the NHS's cache then if that cache
entry also has the uniqueness bit on then this NAK Code is
returned in the CIE in the NHRP Registration Reply.
Due to the possible existence of asymmetric routing, an NHRP
Registration Reply may not be able to merely follow the routed path
back to the source protocol address specified in the common header of
the NHRP Registration Reply. As a result, there MUST exist a direct
NBMA level connection between the NHC and its NHS on which to send
the NHRP Registration Reply before NHRP Registration Reply may be
returned to the NHC. If such a connection does not exist then the
NHS must setup such a connection to the NHC by using the source NBMA
information supplied in the common header of the NHRP Registration
Request.
5.2.5 NHRP Purge Request
The NHRP Purge Request packet is sent in order to invalidate cached
information in a station. The NHRP Purge Request packet has a type
code of 5. The mandatory part of an NHRP Purge Request is coded as
described in Section 5.2.0.1. The message specific meanings of the
fields are as follows:
Flags - The flags field is coded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N
When set, this bit tells the receiver of the NHRP Purge Request
that the requester does not expect to receive an NHRP Purge
Reply. If an unsolicited NHRP Purge Reply is received by a
station where that station is identified in the Source Protocol
Address of the packet then that packet must be ignored.
One or more CIEs are specified in the NHRP Purge Request. Each CIE
contains next hop information which is to be purged from an NHS/NHC
cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests
are coded as described in Section 5.2.0.1. Below, further
clarification is given for some fields in a CIE in the context of a
NHRP Purge Request.
Code
This field is set to 0x00 in NHRP Purge Requests.
Prefix Length
In the case of NHRP Purge Requests, the Prefix Length specifies
the equivalence class of addresses which match the first "Prefix
Length" bit positions of the Client Protocol Address specified in
the CIE. All next hop information which contains a protocol
address which matches an element of this equivalence class is to
be purged from the receivers cache.
The Maximum Transmission Unit and Preference fields of the CIE are
coded as zero. The Holding Time should be coded as zero but there
may be some utility in supplying a "short" holding time to be
applied to the matching next hop information before that
information would be purged; this usage is for further study. The
Client Protocol Address field and the Cli Proto Len field MUST be
filled in. The Client Protocol Address is filled in with the
protocol address to be purged from the receiving station's cache
while the Cli Proto Len is set the length of the purged client's
protocol address. All remaining fields in the CIE MAY be set to
zero although the client NBMA information (and associated length
fields) MAY be specified to narrow the scope of the NHRP Purge
Request if requester desires. However, the receiver of an NHRP
Purge Request may choose to ignore the Client NBMA information if
it is supplied.
An NHRP Purge Request packet is sent from an NHS to a station to
cause it to delete previously cached information. This is done when
the information may be no longer valid (typically when the NHS has
previously provided next hop information for a station that is not
directly connected to the NBMA subnetwork, and the egress point to
that station may have changed).
An NHRP Purge Request packet may also be sent from an NHC to an NHS
with which the NHC had previously registered. This allows for an NHC
to invalidate its registration with NHRP before it would otherwise
expire via the holding timer. If an NHC does not have knowledge of a
protocol address of a serving NHS then the NHC must place its own
protocol address in the Destination Protocol Address field and
forward the packet along the routed path. Otherwise, the NHC must
place the protocol address of a serving NHS in this field.
Serving NHSs may need to send one or more new NHRP Purge Requests as
a result of receiving a purge from one of their served NHCs since the
NHS may have previously responded to NHRP Resolution Requests for
that NHC's NBMA information. These purges are "new" in that they are
sourced by the NHS and not the NHC; that is, for each NHC that
previously sent a NHRP Resolution Request for the purged NHC NBMA
information, an NHRP Purge Request is sent which contains the Source
Protocol/NBMA Addresses of the NHS and the Destination Protocol
Address of the NHC which previously sent an NHRP Resolution Request
prior to the purge.
The station sending the NHRP Purge Request MAY periodically
retransmit the NHRP Purge Request until either NHRP Purge Request is
acknowledged or until the holding time of the information being
purged has expired. Retransmission strategies for NHRP Purge Requests
are a local matter.
When a station receives an NHRP Purge Request, it MUST discard any
previously cached information that matches the information in the
CIEs.
An NHRP Purge Reply MUST be returned for the NHRP Purge Request even
if the station does not have a matching cache entry assuming that the
"N" bit is off in the NHRP Purge Request.
If the station wishes to reestablish communication with the
destination shortly after receiving an NHRP Purge Request, it should
make an authoritative NHRP Resolution Request in order to avoid any
stale cache entries that might be present in intermediate NHSs (See
section 6.2.2.). It is recommended that authoritative NHRP
Resolution Requests be made for the duration of the holding time of
the old information.
5.2.6 NHRP Purge Reply
The NHRP Purge Reply packet is sent in order to assure the sender of
an NHRP Purge Request that all cached information of the specified
type has been purged from the station sending the reply. The NHRP
Purge Reply has a type code of 6.
An NHRP Purge Reply is formed from an NHRP Purge Request by merely
changing the type code in the request to 6. The packet is then
returned to the requester after filling in the appropriate extensions
if they exist.
5.2.7 NHRP Error Indication
The NHRP Error Indication is used to convey error indications to the
sender of an NHRP packet. It has a type code of 7. The Mandatory
Part has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Proto Len | Dst Proto Len | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source NBMA Subaddress (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Protocol Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of NHRP Packet in error (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src Proto Len
This field holds the length in octets of the Source Protocol
Address.
Dst Proto Len
This field holds the length in octets of the Destination Protocol
Address.
Error Code
An error code indicating the type of error detected, chosen from
the following list:
1 - Unrecognized Extension
When the Compulsory bit of an extension in NHRP packet is set,
the NHRP packet cannot be processed unless the extension has
been processed. The responder MUST return an NHRP Error
Indication of type Unrecognized Extension if it is incapable of
processing the extension. However, if a transit NHS (one which
is not going to generate a reply) detects an unrecognized
extension, it SHALL ignore the extension.
3 - NHRP Loop Detected
A Loop Detected error is generated when it is determined that
an NHRP packet is being forwarded in a loop.
6 - Protocol Address Unreachable
This error occurs when a packet it moving along the routed path
and it reaches a point such that the protocol address of
interest is not reachable.
7 - Protocol Error
A generic packet processing error has occurred (e.g., invalid
version number, invalid protocol type, failed checksum, etc.)
8 - NHRP SDU Size Exceeded
If the SDU size of the NHRP packet exceeds the MTU size of the
NBMA network then this error is returned.
9 - Invalid Extension
If an NHS finds an extension in a packet which is inappropriate
for the packet type, an error is sent back to the sender with
Invalid Extension as the code.
10 - Invalid NHRP Resolution Reply Received
If a client receives a NHRP Resolution Reply for a Next Hop
Resolution Request which it believes it did not make then an
error packet is sent to the station making the reply with an
error code of Invalid Reply Received.
11 - Authentication Failure
If a received packet fails an authentication test then this
error is returned.
15 - Hop Count Exceeded
The hop count which was specified in the Fixed Header of an
NHRP message has been exceeded.
Error Offset
The offset in octets into the original NHRP packet in which an
error was detected. This offset is calculated starting from the
NHRP Fixed Header.
Source NBMA Address
The Source NBMA address field is the address of the station which
observed the error.
Source NBMA SubAddress
The Source NBMA subaddress field is the address of the station
which observed the error. If the field's length as specified in
ar$sstl is 0 then no storage is allocated for this address at all.
Source Protocol Address
This is the protocol address of the station which issued the Error
packet.
Destination Protocol Address
This is the protocol address of the station which sent the packet
which was found to be in error.
An NHRP Error Indication packet SHALL NEVER be generated in response
to another NHRP Error Indication packet. When an NHRP Error
Indication packet is generated, the offending NHRP packet SHALL be
discarded. In no case should more than one NHRP Error Indication
packet be generated for a single NHRP packet.
If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA
and Source Protocol address fields of a transiting NHRP Error
Indication packet then the NHS will quietly drop the packet and do
nothing (this scenario would occur when the NHRP Error Indication
packet was itself in a loop).
Note that no extensions may be added to an NHRP Error Indication.
5.3 Extensions Part
The Extensions Part, if present, carries one or more extensions in
{Type, Length, Value} triplets.
Extensions have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C
"Compulsory." If clear, and the NHS does not recognize the type
code, the extension may safely be ignored. If set, and the NHS
does not recognize the type code, the NHRP "request" is considered
to be in error. (See below for details.)
u
Unused and must be set to zero.
Type
The extension type code (see below). The extension type is not
qualified by the Compulsory bit, but is orthogonal to it.
Length
The length in octets of the value (not including the Type and
Length fields; a null extension will have only an extension header
and a length of zero).
When extensions exist, the extensions list is terminated by the Null
TLV, having Type = 0 and Length = 0.
Extensions may occur in any order, but any particular extension type
may occur only once in an NHRP packet unless explicitly stated to the
contrary in the extensions definition. For example, the vendor-
private extension may occur multiple times in a packet in order to
allow for extensions which do not share the same vendor ID to be
represented. It is RECOMMENDED that a given vendor include no more
than one Vendor Private Extension.
An NHS MUST NOT change the order of extensions. That is, the order
of extensions placed in an NHRP packet by an NHC (or by an NHS when
an NHS sources a packet) MUST be preserved as the packet moves
between NHSs. Minimal NHC implementations MUST only recognize, but
not necessarily parse, the Vendor Private extension and the End Of
Extensions extension. Extensions are only present in a "reply" if
they were present in the corresponding "request" with the exception
of Vendor Private extensions. The previous statement is not intended
to preclude the creation of NHS-only extensions which might be added
to and removed from NHRP packets by the same NHS; such extensions
MUST not be propagated to NHCs.
The Compulsory bit provides for a means to add to the extension set.
If the bit is set in an extension then the station responding to the
NHRP message which contains that extension MUST be able to understand
the extension (in this case, the station responding to the message is
the station that would issue an NHRP reply in response to a NHRP
request). As a result, the responder MUST return an NHRP Error
Indication of type Unrecognized Extension. If the Compulsory bit is
clear then the extension can be safely ignored; however, if an
ignored extension is in a "request" then it MUST be returned,
unchanged, in the corresponding "reply" packet type.
If a transit NHS (one which is not going to generate a "reply")
detects an unrecognized extension, it SHALL ignore the extension. If
the Compulsory bit is set, the transit NHS MUST NOT cache the
information contained in the packet and MUST NOT identify itself as
an egress router (in the Forward Record or Reverse Record
extensions). Effectively, this means, if a transit NHS encounters an
extension which it cannot process and which has the Compulsory bit
set then that NHS MUST NOT participate in any way in the protocol
exchange other than acting as a forwarding agent.
The NHRP extension Type space is subdivided to encourage use outside
the IETF.
0x0000 - 0x0FFF Reserved for NHRP.
0x1000 - 0x11FF Allocated to the ATM Forum.
0x1200 - 0x37FF Reserved for the IETF.
0x3800 - 0x3FFF Experimental use.
IANA will administer the ranges reserved for the IETF as described in
Section 9. Values in the 'Experimental use' range have only local
significance.
5.3.0 The End Of Extensions
Compulsory = 1
Type = 0
Length = 0
When extensions exist, the extensions list is terminated by the End
Of Extensions/Null TLV.
5.3.1 Responder Address Extension
Compulsory = 1
Type = 3
Length = variable
This extension is used to determine the address of the NHRP
responder; i.e., the entity that generates the appropriate "reply"
packet for a given "request" packet. In the case of an NHRP
Resolution Request, the station responding may be different (in the
case of cached replies) than the system identified in the Next Hop
field of the NHRP Resolution Reply. Further, this extension may aid
in detecting loops in the NHRP forwarding path.
This extension uses a single CIE with the extension specific meanings
of the fields set as follows:
The Prefix Length fields MUST be set to 0 and ignored.
CIE Code
5 - Insufficient Resources
If the responder to an NHRP Resolution Request is an egress point
for the target of the address resolution request (i.e., it is one
of the stations identified in the list of CIEs in an NHRP
Resolution Reply) and the Responder Address extension is included
in the NHRP Resolution Request and insufficient resources to
setup a cut-through VC exist at the responder then the Code field
of the Responder Address Extension is set to 5 in order to tell
the client that a VC setup attempt would in all likelihood be
rejected; otherwise this field MUST be coded as a zero. NHCs MAY
use this field to influence whether they attempt to setup a cut-
through to the egress router.
Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the
responder. If this value is 0 then either the default MTU is used
or the MTU negotiated via signaling is used if such negotiation is
possible for the given NBMA.
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information of the responser is considered to be valid.
Cached information SHALL be discarded when the holding time
expires.
"Client Address" information is actually "Responder Address"
information for this extension. Thus, for example, Cli Addr T/L is
the responder NBMA address type and length field.
If a "requester" desires this information, the "requester" SHALL
include this extension with a value of zero. Note that this implies
that no storage is allocated for the Holding Time and Type/Length
fields until the "Value" portion of the extension is filled out.
If an NHS is generating a "reply" packet in response to a "request"
containing this extension, the NHS SHALL include this extension,
containing its protocol address in the "reply". If an NHS has more
than one protocol address, it SHALL use the same protocol address
consistently in all of the Responder Address, Forward Transit NHS
Record, and Reverse Transit NHS Record extensions. The choice of
which of several protocol address to include in this extension is a
local matter.
If an NHRP Resolution Reply packet being forwarded by an NHS contains
a protocol address of that NHS in the Responder Address Extension
then that NHS SHALL generate an NHRP Error Indication of type "NHRP
Loop Detected" and discard the NHRP Resolution Reply.
If an NHRP Resolution Reply packet is being returned by an
intermediate NHS based on cached data, it SHALL place its own address
in this extension (differentiating it from the address in the Next
Hop field).
5.3.2 NHRP Forward Transit NHS Record Extension
Compulsory = 1
Type = 4
Length = variable
The NHRP Forward Transit NHS record contains a list of transit NHSs
through which a "request" has traversed. Each NHS SHALL append to
the extension a Forward Transit NHS element (as specified below)
containing its Protocol address. The extension length field and the
ar$chksum fields SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension.
In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information
about their NBMA Address.
This extension uses a single CIE per NHS Record element with the
extension specific meanings of the fields set as follows:
The Prefix Length fields MUST be set to 0 and ignored.
CIE Code
5 - Insufficient Resources
If an NHRP Resolution Request contains an NHRP Forward Transit
NHS Record Extension and insufficient resources to setup a cut-
through VC exist at the current transit NHS then the CIE Code
field for NHRP Forward Transit NHS Record Extension is set to 5
in order to tell the client that a VC setup attempt would in all
likelihood be rejected; otherwise this field MUST be coded as a
zero. NHCs MAY use this field to influence whether they attempt
to setup a cut-through as described in Section 2.2. Note that
the NHRP Reverse Transit NHS Record Extension MUST always have
this field set to zero.
Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA.
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information of the transit NHS is considered to be valid.
Cached information SHALL be discarded when the holding time
expires.
"Client Address" information is actually "Forward Transit NHS
Address" information for this extension. Thus, for example, Cli Addr
T/L is the transit NHS NBMA address type and length field.
If a "requester" wishes to obtain this information, it SHALL include
this extension with a length of zero. Note that this implies that no
storage is allocated for the Holding Time and Type/Length fields
until the "Value" portion of the extension is filled out.
If an NHS has more than one Protocol address, it SHALL use the same
Protocol address consistently in all of the Responder Address,
Forward NHS Record, and Reverse NHS Record extensions. The choice of
which of several Protocol addresses to include in this extension is a
local matter.
If a "request" that is being forwarded by an NHS contains the
Protocol Address of that NHS in one of the Forward Transit NHS
elements then the NHS SHALL generate an NHRP Error Indication of type
"NHRP Loop Detected" and discard the "request".
5.3.3 NHRP Reverse Transit NHS Record Extension
Compulsory = 1
Type = 5
Length = variable
The NHRP Reverse Transit NHS record contains a list of transit NHSs
through which a "reply" has traversed. Each NHS SHALL append a
Reverse Transit NHS element (as specified below) containing its
Protocol address to this extension. The extension length field and
ar$chksum SHALL be adjusted appropriately.
The responding NHS, as described in Section 5.3.1, SHALL NOT update
this extension.
In addition, NHSs that are willing to act as egress routers for
packets from the source to the destination SHALL include information
about their NBMA Address.
This extension uses a single CIE per NHS Record element with the
extension specific meanings of the fields set as follows:
The CIE Code and Prefix Length fields MUST be set to 0 and ignored.
Maximum Transmission Unit
This field gives the maximum transmission unit preferred by the
transit NHS. If this value is 0 then either the default MTU is
used or the MTU negotiated via signaling is used if such
negotiation is possible for the given NBMA.
Holding Time
The Holding Time field specifies the number of seconds for which
the NBMA information of the transit NHS is considered to be valid.
Cached information SHALL be discarded when the holding time
expires.
"Client Address" information is actually "Reverse Transit NHS
Address" information for this extension. Thus, for example, Cli Addr
T/L is the transit NHS NBMA address type and length field.
If a "requester" wishes to obtain this information, it SHALL include
this extension with a length of zero. Note that this implies that no
storage is allocated for the Holding Time and Type/Length fields
until the "Value" portion of the extension is filled out.
If an NHS has more than one Protocol address, it SHALL use the same
Protocol address consistently in all of the Responder Address,
Forward NHS Record, and Reverse NHS Record extensions. The choice of
which of several Protocol addresses to include in this extension is a
local matter.
If a "reply" that is being forwarded by an NHS contains the Protocol
Address of that NHS in one of the Reverse Transit NHS elements then
the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
Detected" and discard the "reply".
Note that this information may be cached at intermediate NHSs; if
so, the cached value SHALL be used when generating a reply.
5.3.4 NHRP Authentication Extension
Compulsory = 1 Type = 7 Length = variable
The NHRP Authentication Extension is carried in NHRP packets to
convey authentication information between NHRP speakers. The
Authentication Extension may be included in any NHRP "request" or
"reply" only.
The authentication is always done pairwise on an NHRP hop-by-hop
basis; i.e., the authentication extension is regenerated at each
hop. If a received packet fails the authentication test, the station
SHALL generate an Error Indication of type "Authentication Failure"
and discard the packet. Note that one possible authentication failure
is the lack of an Authentication Extension; the presence or absence
of the Authentication Extension is a local matter.
5.3.4.1 Header Format
The authentication header has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Parameter Index (SPI)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Addr... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Security Parameter Index (SPI) can be thought of as an index into a
table that maintains the keys and other information such as hash
algorithm. Src and Dst communicate either offline using manual keying
or online using a key management protocol to populate this table. The
sending NHRP entity always allocates the SPI and the parameters
associated with it.
Src Addr a variable length field is the address assigned to the
outgoing interface. The length of the addr is obtained from the
source protocol length field in the mandatory part of the NHRP
header. The tuple <spi, src addr> uniquely identifies the key and
other parameters that are used in authentication.
The length of the authentication data field is dependent on the hash
algorithm used. The data field contains the keyed hash calculated
over the entire NHRP payload. The authentication data field is zeroed
out before the hash is calculated.
5.3.4.2 SPI and Security Parameters Negotiation
SPI's can be negotiated either manually or using an Internet Key
Management protocol. Manual keying MUST be supported. The following
parameters are associated with the tuple <SPI, src>- lifetime,
Algorithm, Key. Lifetime indicates the duration in seconds for which
the key is valid. In case of manual keying, this duration can be
infinite. Also, in order to better support manual keying, there may
be multiple tuples active at the same time (Dst being the same).
Algorithm specifies the hash algorithm agreed upon by the two
entities. HMAC-MD5-128 [16] is the default algorithm. Other
algorithms MAY be supported by defining new values. IANA will assign
the numbers to identify the algorithm being used as described in
Section 9.
Any Internet standard key management protocol MAY so be used to
negotiate the SPI and parameters.
5.3.4.3 Message Processing
At the time of adding the authentication extension header, src looks
up in a table to fetch the SPI and the security parameters based on
the outgoing interface address. If there are no entries in the table
and if there is support for key management, the src initiates the key
management protocol to fetch the necessary parameters. The src
constructs the Authentication Extension payload and calculates the
hash by zeroing authentication data field. The result replaces in the
zeroed authentication data field. The src address field in the
payload is the IP address assigned to the outgoing interface.
If key management is not supported and authentication is mandatory,
the packet is dropped and this information is logged.
On the receiving end, dst fetches the parameters based on the SPI and
the ip address in the authentication extension payload. The
authentication data field is extracted before zeroing out to
calculate the hash. It computes the hash on the entire payload and if
the hash does not match, then an "abnormal event" has occurred.
5.3.4.4 Security Considerations
It is important that the keys chosen are strong as the security of
the entire system depends on the keys being chosen properly and the
correct implementation of the algorithms.
The security is performed on a hop by hop basis. The data received
can be trusted only so much as one trusts all the entities in the
path traversed. A chain of trust is established amongst NHRP entities
in the path of the NHRP Message . If the security in an NHRP entity
is compromised, then security in the entire NHRP domain is
compromised.
Data integrity covers the entire NHRP payload. This guarantees that
the message was not modified and the source is authenticated as well.
If authentication extension is not used or if the security is
compromised, then NHRP entities are liable to both spoofing attacks,
active attacks and passive attacks.
There is no mechanism to encrypt the messages. It is assumed that a
standard layer 3 confidentiality mechanism will be used to encrypt
and decrypt messages. It is recommended to use an Internet standard
key management protocol to negotiate the keys between the neighbors.
Transmitting the keys in clear text, if other methods of negotiation
is used, compromises the security completely.
Any NHS is susceptible to Denial of Service (DOS) attacks that cause
it to become overloaded, preventing legitimate packets from being
acted upon properly. A rogue host can send request and registration
packets to the first hop NHS. If the authentication option is not
used, the registration packet is forwarded along the routed path
requiring processing along each NHS. If the authentication option is
used, then only the first hop NHS is susceptible to DOS attacks
(i.e., unauthenticated packets will be dropped rather than forwarded
on). If security of any host is compromised (i.e., the keys it is
using to communicate with an NHS become known), then a rogue host can
send NHRP packets to the first hop NHS of the host whose keys were
compromised, which will then forward them along the routed path as in
the case of unauthenticated packets. However, this attack requires
that the rogue host to have the same first hop NHS as that of the
compromised host. Finally, it should be noted that denial of service
attacks that cause routers on the routed path to expend resources
processing NHRP packets are also susceptable to attacks that flood
packets at the same destination as contained in an NHRP packet's
Destination Protocol Address field.
5.3.5 NHRP Vendor-Private Extension
Compulsory = 0
Type = 8
Length = variable
The NHRP Vendor-Private Extension is carried in NHRP packets to
convey vendor-private information or NHRP extensions between NHRP
speakers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Data.... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID
802 Vendor ID as assigned by the IEEE [6]
Data
The remaining octets after the Vendor ID in the payload are
vendor-dependent data.
This extension may be added to any "request" or "reply" packet and it
is the only extension that may be included multiple times. If the
receiver does not handle this extension, or does not match the Vendor
ID in the extension then the extension may be completely ignored by
the receiver. If a Vendor Private Extension is included in a
"request" then it must be copied to the corresponding "reply".
6. Protocol Operation
In this section, we discuss certain operational considerations of
NHRP.
6.1 Router-to-Router Operation
In practice, the initiating and responding stations may be either
hosts or routers. However, there is a possibility under certain
conditions that a stable routing loop may occur if NHRP is used
between two routers. In particular, attempting to establish an NHRP
path across a boundary where information used in route selection is
lost may result in a routing loop. Such situations include the loss
of BGP path vector information, the interworking of multiple routing
protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such
circumstances, NHRP should not be used. This situation can be
avoided if there are no "back door" paths between the entry and
egress router outside of the NBMA subnetwork. Protocol mechanisms to
relax these restrictions are under investigation.
In general it is preferable to use mechanisms, if they exist, in
routing protocols to resolve the egress point when the destination
lies outside of the NBMA subnetwork, since such mechanisms will be
more tightly coupled to the state of the routing system and will
probably be less likely to create loops.
6.2 Cache Management Issues
The management of NHRP caches in the source station, the NHS serving
the destination, and any intermediate NHSs is dependent on a number
of factors.
6.2.1 Caching Requirements
Source Stations
Source stations MUST cache all received NHRP Resolution Replies
that they are actively using. They also must cache "incomplete"
entries, i.e., those for which a NHRP Resolution Request has been
sent but those for which an NHRP Resolution Reply has not been