idnits 2.17.1 draft-ietf-rolc-nhrp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 132 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 259: '...n Request for a given destination MUST...' RFC 2119 keyword, line 291: '...n Request. NHSs MUST NOT respond to a...' RFC 2119 keyword, line 338: '...and NHRP Replies MUST NOT cross the bo...' RFC 2119 keyword, line 464: '... 5.3.2). An NHS MAY also be configure...' RFC 2119 keyword, line 491: '...e Mandatory Part MUST be present, but ...' (86 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 890 has weird spacing: '... wishes to r...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Extensions Part, if present, carries one or more extensions in {Type, Length, Value} triplets. Extensions are only present in a "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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1996) is 9987 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0xAA-AA-03' on line 511 -- Looks like a reference, but probably isn't: '0x00-00-5E' on line 511 -- Looks like a reference, but probably isn't: '0x00-03' on line 511 == Unused Reference: '5' is defined on line 2186, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1735 (ref. '1') ** Obsolete normative reference: RFC 1577 (ref. '3') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1483 (ref. '7') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1490 (ref. '9') (Obsoleted by RFC 2427) -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 17 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing over Large Clouds Working Group James V. Luciani 2 INTERNET-DRAFT (Bay Networks) 3 Dave Katz 4 (cisco Systems) 5 David Piscitello 6 (Core Competence, Inc.) 7 Bruce Cole 8 (cisco Systems) 9 Expires December 1996 11 NBMA Next Hop Resolution Protocol (NHRP) 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 34 NHRP can be used by a source station (host or router) connected to a 35 Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the 36 internetworking layer address and NBMA subnetwork addresses of the 37 "NBMA next hop" towards a destination station. If the destination is 38 connected to the NBMA subnetwork, then the NBMA next hop is the 39 destination station itself. Otherwise, the NBMA next hop is the 40 egress router from the NBMA subnetwork that is "nearest" to the 41 destination station. NHRP is intended for use in a multiprotocol 42 internetworking layer environment over NBMA subnetworks. 44 This document is intended to be a functional superset of the NBMA 45 Address Resolution Protocol (NARP) documented in [1]. 47 Operation of NHRP as a means of establishing a transit path across an 48 NBMA subnetwork between two routers will be addressed in a separate 49 document. 51 1. Introduction 53 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 54 (a host or router), wishing to communicate over a Non-Broadcast, 55 Multi-Access (NBMA) subnetwork, to determine the internetworking 56 layer addresses and NBMA addresses of suitable "NBMA next hops" 57 toward a destination station. A subnetwork can be non-broadcast 58 either because it technically doesn't support broadcasting (e.g., an 59 X.25 subnetwork) or because broadcasting is not feasible for one 60 reason or another (e.g., an SMDS multicast group or an extended 61 Ethernet would be too large). If the destination is connected to the 62 NBMA subnetwork, then the NBMA next hop is the destination station 63 itself. Otherwise, the NBMA next hop is the egress router from the 64 NBMA subnetwork that is "nearest" to the destination station. 66 One way to model an NBMA network is by using the notion of logically 67 independent IP subnets (LISs). LISs, as defined in [3] and [4], have 68 the following properties: 70 1) All members of a LIS have the same IP network/subnet number 71 and address mask. 73 2) All members within a LIS are directly connected to the same 74 NBMA subnetwork. 76 3) All members outside of the LIS are accessed via a router. 78 4) All members within the LIS access each other directly 79 (without routers) 81 Address resolution as described in [3] and [4] only resolves the next 82 hop address if the destination station is a member of the same LIS as 83 the source station; otherwise, the source station must forward 84 packets to a router that is a member of multiple LIS's. In multi-LIS 85 configurations, hop-by-hop address resolution may not be sufficient 86 to resolve the "NBMA next hop" toward the destination station, and IP 87 packets may have multiple IP hops through the NBMA subnetwork. 89 Another way to model NBMA is by using the notion of Local Address 90 Groups (LAGs) [10]. The essential difference between the LIS and the 91 LAG models is that while with the LIS model the outcome of the 92 "local/remote" forwarding decision is driven purely by addressing 93 information, with the LAG model the outcome of this decision is 94 decoupled from the addressing information and is coupled with the 95 Quality of Service and/or traffic characteristics. With the LAG 96 model any two entities on a common NBMA network could establish a 97 direct communication with each other, irrespective of the entities' 98 addresses. 100 Support for the LAG model assumes the existence of a mechanism that 101 allows any entity (i.e., host or router) connected to an NBMA network 102 to resolve an internetworking layer address to an NBMA address for 103 any other entity connected to the same NBMA network. This resolution 104 would take place regardless of the address assignments to these 105 entities. NHRP describes such a mechanism. For example, when the 106 internetworking layer address is of type IP, once the NBMA next hop 107 has been resolved, the source may either start sending IP packets to 108 the destination (in a connectionless NBMA subnetwork such as SMDS) or 109 may first establish a connection to the destination with the desired 110 bandwidth and QOS characteristics (in a connection-oriented NBMA 111 subnetwork such as ATM). 113 Use of NHRP may be sufficient for hosts doing address resolution when 114 those hosts are directly connected to an NBMA subnetwork, allowing 115 for straightforward implementations in NBMA stations. NHRP also has 116 the capability of determining the egress point from an NBMA 117 subnetwork when the destination is not directly connected to the NBMA 118 subnetwork and the identity of the egress router is not learned by 119 other methods (such as routing protocols). Optional extensions to 120 NHRP provide additional robustness and diagnosability. 122 Address resolution techniques such as those described in [3] and [4] 123 may be in use when NHRP is deployed. ARP servers and services over 124 NBMA subnetworks may be required to support hosts that are not 125 capable of dealing with any model for communication other than the 126 LIS model, and deployed hosts may not implement NHRP but may continue 127 to support ARP variants such as those described in [3] and [4]. NHRP 128 is intended to reduce or eliminate the extra router hops required by 129 the LIS model, and can be deployed in a non-interfering manner 130 alongside existing ARP services. 132 The operation of NHRP to establish transit paths across NBMA 133 subnetworks between two routers requires additional mechanisms to 134 avoid stable routing loops, and will be described in a separate 135 document. 137 2. Overview 139 2.1 Terminology 141 The term "network" is highly overloaded, and is especially confusing 142 in the context of NHRP. We use the following terms: 144 Internetwork layer--the media-independent layer (IP in the case of 145 TCP/IP networks). 147 Subnetwork layer--the media-dependent layer underlying the 148 internetwork layer, including the NBMA technology (ATM, X.25, SMDS, 149 etc.) 151 The term "server", unless explicitly stated to the contrary, refers 152 to an Next Hop Server (NHS). An NHS is an entity performing the 153 Next Hop Resolution Protocol service within the NBMA cloud. An NHS 154 is always tightly coupled with a routing entity (router, route 155 server or edge device) although the converse is not yet guaranteed 156 until ubiquitous deployment of this functionality occurs. 158 The term "client", unless explicitly stated to the contrary, refers 159 to an Next Hop Resolution Protocol client (NHC). An NHC is an 160 entity which initiates NHRP requests of various types in order to 161 obtain access to the NHRP service. 163 The term "station" generally refers to a host or router which 164 contains an NHRP entity. Occasionally, the term station will 165 describe a "user" of the NHRP client or service functionality; the 166 difference in usage is largely semantic. 168 2.2 Protocol Overview 170 In this section, we briefly describe how a source S (which 171 potentially can be either a router or a host) uses NHRP to determine 172 the "NBMA next hop" to destination D. 174 For administrative and policy reasons, a physical NBMA subnetwork may 175 be partitioned into several, disjoint "Logical NBMA subnetworks". A 176 Logical NBMA subnetwork is defined as a collection of hosts and 177 routers that share unfiltered subnetwork connectivity over an NBMA 178 subnetwork. "Unfiltered subnetwork connectivity" refers to the 179 absence of closed user groups, address screening or similar features 180 that may be used to prevent direct communication between stations 181 connected to the same NBMA subnetwork. (Hereafter, unless otherwise 182 specified, we use the term "NBMA subnetwork" to mean *logical* NBMA 183 subnetwork.) 184 Placed within the NBMA subnetwork are one or more entities that 185 implement the NHRP protocol. Such stations which are capable of 186 answering Next Hop Resolution Requests are known as "Next Hop 187 Servers" (NHSs). Each NHS serves a set of destination hosts, which 188 may or may not be directly connected to the NBMA subnetwork. NHSs 189 cooperatively resolve the NBMA next hop within their logical NBMA 190 subnetwork. In addition to NHRP, NHSs may participate in protocols 191 used to disseminate routing information across (and beyond the 192 boundaries of) the NBMA subnetwork, and may support "classical" ARP 193 service as well. 195 An NHS maintains a "next-hop resolution" cache, which is a table of 196 address mappings (internetwork layer address to NBMA subnetwork layer 197 address). This table can be constructed from information gleaned 198 from NHRP Register packets (see Section 5.2.3 and 5.2.4), extracted 199 from Next Hop Resolution Requests/Replies that traverse the NHS as 200 they are forwarded, or through mechanisms outside the scope of this 201 document (examples of such mechanisms include ARP [2, 3, 4] and pre- 202 configured tables). Section 6.2 further describes cache management 203 issues. 205 A host or router that is not an NHRP server must be configured with 206 the identity of the NHS which serves it (see Configuration, Section 207 4). 209 [Note: for NBMA subnetworks that offer group or multicast addressing 210 features, it may be desirable to configure stations with a group 211 identity for NHSs, i.e., addressing information that would solicit a 212 response from "all NHSs". The means whereby a group of NHSs divide 213 responsibilities for next hop resolution are not described here.] 215 Whether or not a particular station within the NBMA subnetwork which 216 is making use of the NHRP protocol needs to be able to act as an NHS 217 is a local matter. For a station to avoid providing NHS 218 functionality, there must be one or more NHSs within the NBMA 219 subnetwork which are providing authoritative NBMA information on its 220 behalf. If NHRP is to be able to resolve the NBMA address for 221 stations that lack NHS functionality, these serving NHSs must exist 222 along all routed paths between Next Hop Resolution Requesters and the 223 station which cannot answer Next Hop Resolution Requests. 225 The protocol proceeds as follows. An event occurs triggering station 226 S to want to resolve the NBMA address of a path to D. This is most 227 likely to be when a data packet addressed to station D is to be 228 emitted from station S (either because station S is a host, or 229 station S is a transit router), but the address resolution could also 230 be triggered by other means (a routing protocol update packet, for 231 example). Station S first determines the next hop to station D 232 through normal routing processes (for a host, the next hop may simply 233 be the default router; for routers, this is the "next hop" to the 234 destination internetwork layer address). If the next hop is 235 reachable through one of its NBMA interfaces, S constructs an Next 236 Hop Resolution Request packet (see Section 5.2.1) containing station 237 D's internetwork layer address as the (target) destination address, 238 S's own internetwork layer address as the source address (Next Hop 239 Resolution Request initiator), and station S's NBMA addressing 240 information. Station S may also indicate that it prefers an 241 authoritative Next Hop Resolution Reply (i.e., station S only wishes 242 to receive a Next Hop Resolution Reply from the NHS-speaker that 243 maintains the NBMA-to-internetwork layer address mapping for this 244 destination). Station S emits the Next Hop Resolution Request packet 245 towards the destination. 247 If the Next Hop Resolution Request is triggered by a data packet, 248 station S may choose to dispose of the data packet while awaiting a 249 Next Hop Resolution Reply in one of the following ways: 251 (a) Drop the packet 252 (b) Retain the packet until the Next Hop Resolution Reply arrives 253 and a more optimal path is available 254 (c) Forward the packet along the routed path toward D 256 The choice of which of the above to perform is a local policy matter, 257 though option (c) is the recommended default, since it may allow data 258 to flow to the destination while the NBMA address is being resolved. 259 Note that an Next Hop Resolution Request for a given destination MUST 260 NOT be triggered on every packet, though periodically retrying a Next 261 Hop Resolution Request is permitted. 263 When the NHS receives an Next Hop Resolution Request, a check is made 264 to see if it "serves" station D, i.e., the NHS checks to see if there 265 is a "next hop" entry for D in its next-hop resolution cache. If the 266 NHS does not serve D, the NHS forwards the Next Hop Resolution 267 Request to another NHS. (Mechanisms for determining how to forward 268 the Next Hop Resolution Request are discussed in Section 3, 269 Deployment.) Note that NHSs must be next hops to one another in order 270 for forwarding of NHRP packets to be possible. 272 If this NHS serves D, the NHS resolves station D's NBMA address, and 273 generates a positive Next Hop Resolution Reply (denoted by a 0 Code 274 in the reply) on D's behalf. (Next Hop Resolution Replies in this 275 scenario are always marked as "authoritative".) The Next Hop 276 Resolution Reply packet contains the next hop internetwork layer 277 address and the NBMA address for station D and is sent back to S. 278 (Note that if station D is not on the NBMA subnetwork, the next hop 279 internetwork layer address will be that of the egress router through 280 which packets for station D are forwarded.) 282 An NHS receiving a Next Hop Resolution Reply may cache the NBMA next 283 hop information contained therein. To a subsequent Next Hop 284 Resolution Request, this NHS may respond with the cached, non- 285 authoritative, NBMA next hop information or with cached negative 286 information, if the NHS is allowed to do so, see section 5.2.2 and 287 6.2. Non-authoritative Next Hop Resolution Replies are distinguished 288 from authoritative Next Hop Resolution Replies so that if a 289 communication attempt based on non-authoritative information fails, a 290 source station can choose to send an authoritative Next Hop 291 Resolution Request. NHSs MUST NOT respond to authoritative Next Hop 292 Resolution Requests with cached information. 294 [Note: An Next Hop Resolution Reply can be returned directly to the 295 Next Hop Resolution Request initiator, i.e., without traversing the 296 list of NHSs that forwarded the Next Hop Resolution Request, if all 297 of the following criteria are satisfied: 299 (a) Direct communication is available via datagram transfer 300 (e.g., SMDS) or the NHS has an existing virtual circuit 301 connection to the Next Hop Resolution Request initiator or is 302 permitted to open one. 303 (b) The Next Hop Resolution Request initiator has not included the 304 NHRP Reverse NHS record Extension (see Section 5.3.5). 305 (c) The authentication policy in force permits direct 306 communication between the NHS and the Next Hop Resolution 307 Request initiator. 309 The purpose of allowing an NHS to send a Next Hop Resolution Reply 310 directly is to reduce response time. A consequence of allowing a 311 direct Next Hop Resolution Reply is that NHSs that would under 312 normal circumstances be traversed by the Next Hop Resolution Reply 313 would not cache next hop information contained therein.] 315 The process of forwarding the Next Hop Resolution Request is repeated 316 until the Next Hop Resolution Request is satisfied, or an error 317 occurs (e.g., no NHS in the NBMA subnetwork can resolve the Next Hop 318 Resolution Request.) If the determination is made that station D's 319 next hop cannot be resolved, a negative Next Hop Resolution Reply 320 (NAK) is returned. This occurs when (a) no next-hop resolution 321 information is available for station D from any NHS, or (b) an NHS is 322 unable to forward the Next Hop Resolution Request (e.g., connectivity 323 is lost). 325 NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, 326 and NHRP Error Indications follow the routed path from sender to 327 receiver in the same fashion that Next Hop Resolution Requests and 328 Next Hop Resolution Replies do. That is, "requests" and 329 "indications" follow the routed path from Source Protocol Address 330 (which is the address of the station initiating the communication) to 331 the Destination Protocol Address. "Replies", on the other hand, 332 follow the routed path from the Destination Protocol Address back to 333 the Source Protocol Address with the exceptions mentioned above where 334 a direct VC may be created. In the case of a NHRP Registration 335 Reply, the packet is always returned via a direct VC (see Section 336 5.2.4). 338 NHRP Requests and NHRP Replies MUST NOT cross the borders of a 339 logical NBMA subnetwork (an explicit NBMA subnetwork identifier may 340 be included as an extension in the Next Hop Resolution Request, see 341 section 5.3.2). Thus, the internetwork layer traffic out of and into 342 a logical NBMA subnetwork always traverses an internetwork layer 343 router at its border. Internetwork layer filtering can then be 344 implemented at these border routers. 346 NHRP optionally provides a mechanism to send a Next Hop Resolution 347 Reply which contains aggregated NBMA next hop information. Suppose 348 that router X is the NBMA next hop from station S to station D. 349 Suppose further that X is an egress router for all stations sharing 350 an internetwork layer address prefix with station D. When an Next 351 Hop Resolution Reply is generated in response to a Next Hop 352 Resolution Request, the responder may augment the internetwork layer 353 address of station D with a prefix length (see Section 5.2.0.1). A 354 subsequent (non-authoritative) Next Hop Resolution Request for some 355 destination that shares an internetwork layer address prefix (for the 356 number of bits specified in the prefix length) with D may be 357 satisfied with this cached information. See section 6.2 regarding 358 caching issues. 360 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 361 (e.g., X.25 closed user group facility, or SMDS address screens), to 362 trace the routed path that an NHRP packet takes, or to provide loop 363 detection and diagnostic capabilities, a "Route Record" may be 364 included in NHRP packets (see Sections 5.3.4 and 5.3.5). The Route 365 Record extensions contain the internetwork (and subnetwork layer) 366 addresses of all intermediate NHSs between source and destination (in 367 the forward direction) and between destination and source (in the 368 reverse direction). When a source station is unable to communicate 369 with the responder (e.g., an attempt to open an SVC fails), it may 370 attempt to do so successively with other subnetwork layer addresses 371 in the Route Record until it succeeds (if authentication policy 372 permits such action). This approach can find a suitable egress point 373 in the presence of subnetwork-layer filtering (which may be 374 source/destination sensitive, for instance, without necessarily 375 creating separate logical NBMA subnetworks) or subnetwork-layer 376 congestion (especially in connection-oriented media). 378 3. Deployment 380 Next Hop Resolution Requests traverse one or more hops within an NBMA 381 subnetwork before reaching the station that is expected to generate a 382 response. Each station, including the source station, chooses a 383 neighboring NHS to which it will forward the Next Hop Resolution 384 Request. The NHS selection procedure typically involves applying a 385 destination protocol layer address to the protocol layer routing 386 table which causes a routing decision to be returned. This routing 387 decision is then used to forward the Next Hop Resolution Request to 388 the downstream NHS. The destination protocol layer address previously 389 mentioned is carried within the Next Hop Resolution Request packet. 390 Note that even though a protocol layer address was used to acquire a 391 routing decision, NHRP packets are not encapsulated within a protocol 392 layer header but rather are carried at the NBMA layer using the 393 encapsulation described in Section 5. 395 Each NHS/router examines the Next Hop Resolution Request packet on 396 its way toward the destination. Each NHS which the NHRP packet 397 traverses on the way to the packet's destination might modify the 398 packet (e.g., updating the Forward Record extension). Ignoring error 399 situations, the Next Hop Resolution Request eventually arrives at a 400 station that is to generate an Next Hop Resolution Reply. This 401 responding station "serves" the destination. The responding station 402 generates a Next Hop Resolution Reply using the source protocol 403 address from within the NHRP packet to determine where the Next Hop 404 Resolution Reply should be sent. 406 Rather than use routing to determine the next hop for an NHRP packet, 407 an NHS may use static configuration information (or other applicable 408 means) in order to determine to which neighboring NHSs to forward the 409 Next Hop Resolution Request packet. The use of static configuration 410 information for this purpose is beyond the scope of this document. 412 In order to forward NHRP packets to a neighboring NHS, NHRP clients 413 must nominally be configured with the NBMA address of at least one 414 NHS. In practice, a client's default router should also be its NHS 415 in that way a client may be able to know the NBMA address of its NHS 416 from the configuration which was already required for the client to 417 be able to communicate. 419 The NHS serving a particular destination must lie along the routed 420 path to that destination. In practice, this means that all egress 421 routers must double as NHSs serving the destinations beyond them, and 422 that hosts on the NBMA subnetwork are served by routers that double 423 as NHSs. Also, this implies that forwarding of NHRP packets within 424 an NBMA subnetwork requires a contiguous deployment of NHRP capable 425 routers. During migration to NHRP, it cannot be expected that all 426 routers within the NBMA subnetwork are NHRP capable. Thus, NHRP 427 traffic which would otherwise need to be forwarded through such 428 routers can be expected to be dropped due to the NHRP packet not 429 being recognized. In this case, NHRP will be unable to establish any 430 transit paths whose discovery requires the traversal of the non-NHRP 431 speaking routers. If the client has tried and failed to acquire a 432 cut through path then the client should use the network layer routed 433 path as a default. 435 If a subnetwork offers a link layer group addressing or multicast 436 feature, the client (station) may be configured with a group address 437 assigned to the group of next-hop servers. The client might then 438 submit Next Hop Resolution Requests to the group address, eliciting a 439 response from one or more NHSs, depending on the response strategy 440 selected. Note that the constraints described in Section 2 regarding 441 directly sending Next Hop Resolution Reply may apply. 443 4. Configuration 445 Clients 447 To participate in NHRP, a client connected to an NBMA subnetwork 448 should be configured with the NBMA address(es) of its NHS(s) 449 (alternatively, it should be configured with a means of acquiring 450 them, i.e., the group address that members of a NHS group use for 451 the purpose of address or next-hop resolution.) The NHS(s) will 452 likely also represent the client's default or peer routers, so 453 their NBMA addresses may be obtained from the client's existing 454 configuration. If the client is attached to several subnetworks 455 (including logical NBMA subnetworks), the client should also be 456 configured to receive routing information from its NHS(s) and peer 457 routers so that it can determine which internetwork layer networks 458 are reachable through which subnetworks. 460 Next Hop Servers 462 An NHS is configured with knowledge of its own internetwork layer 463 and NBMA addresses and a logical NBMA subnetwork identifier (see 464 Section 5.3.2). An NHS MAY also be configured with a set of 465 internetwork layer address prefixes that correspond to the 466 internetwork layer addresses of the stations it serves. If a served 467 client is attached to several subnetworks, the NHS may also need to 468 be configured to advertise routing information to such client. 470 If an NHS acts as an egress router for stations connected to other 471 subnetworks than the NBMA subnetwork, the NHS must, in addition to 472 the above, be configured to exchange routing information between 473 the NBMA subnetwork and these other subnetworks. 475 In all cases, routing information is exchanged using conventional 476 intra-domain and/or inter-domain routing protocols. 478 The NBMA addresses of the stations served by the NHS may be learned 479 via NHRP Register packets or manual configuration. 481 5. NHRP Packet Formats 482 This section describes the format of NHRP packets. In the following, 483 unless otherwise stated explicitly, the unqualified term "request" 484 refers generically to any of the NHRP packet types which are 485 "requests". Further, unless otherwise stated explicitly, the 486 unqualified term "reply" refers generically to any of the NHRP packet 487 types which are "replies". 489 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 490 Extensions Part. The Fixed Part is common to all NHRP packet types. 491 The Mandatory Part MUST be present, but varies depending on packet 492 type. The Extensions Part also varies depending on packet type, and 493 need not be present. 495 The length of the Fixed Part is fixed at 20 octets. The length of 496 the Mandatory Part is determined by the contents of the extensions 497 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 498 length is equal to total packet length (ar$pktsz) minus 20 otherwise 499 the mandatory part length is equal to ar$extoff minus 20. The length 500 of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs 501 may increase the size of an NHRP packet as a result of extension 502 processing, but not beyond the offered maximum SDU size of the NBMA 503 network. 505 NHRP packets are encapsulated using the native formats used on the 506 particular NBMA network over which NHRP is carried. For example, 507 SMDS networks always use LLC/SNAP encapsulation at the NBMA layer, 508 and an NHRP packet is preceded by the following LLC/SNAP 509 encapsulation: 511 [0xAA-AA-03] [0x00-00-5E] [0x00-03] 513 The first three octets are LLC, indicating that SNAP follows. The 514 SNAP OUI portion is the IANA's OUI, and the SNAP PID portion 515 identifies NHRP (see [4]). 517 ATM uses either LLC/SNAP encapsulation of each packet (including 518 NHRP), or uses no encapsulation on VCs dedicated to a single protocol 519 (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or 520 identification of NHRP, using a NLPID of 0x0080 and the same SNAP 521 contents as above (see [8], [9]). 523 Fields marked "unused" MUST be set to zero on transmission, and 524 ignored on receipt. 526 Most packet types (ar$op.type) have both internetwork layer 527 protocol-independent fields and protocol-specific fields. The 528 protocol type/snap fields (ar$pro.type/snap) qualify the format of 529 the protocol-specific fields. 531 5.1 NHRP Fixed Header 533 The Fixed Part of the NHRP packet contains those elements of the NHRP 534 packet which are always present and do not vary in size with the type 535 of packet. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | ar$afn | ar$pro.type | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | ar$pro.snap | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | ar$pro.snap | ar$hopcnt | ar$pktsz | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | ar$chksum | ar$extoff | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | ar$op.version | ar$op.type | ar$shtl | ar$sstl | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 ar$afn 552 Defines the type of "link layer" addresses being carried. This 553 number is taken from the 'address family number' list specified in 554 [6]. This field has implications to the coding of ar$shtl and 555 ar$sstl as described below. 557 ar$pro.type 558 field is a 16 bit unsigned integer representing the following 559 number space: 561 0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 562 0x0100 to 0x03FF Reserved for future use by the IETF. 564 0x0400 to 0x04FF Allocated for use by the ATM Forum. 565 0x0500 to 0x05FF Experimental/Local use. 566 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 568 (based on the observations that valid Ethertypes are never smaller 569 than 0x600, and NLPIDs never larger than 0xFF.) 571 ar$pro.snap 572 When ar$pro.type has a value of 0x0080, a SNAP encoded extension is 573 being used to encode the protocol type. This snap extension is 574 placed in the ar$pro.snap field. This is termed the 'long form' 575 protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be 576 zero on transmit and ignored on receive. The ar$pro.type field 577 itself identifies the protocol being referred to. This is termed 578 the 'short form' protocol ID. 580 In all cases, where a protocol has an assigned number in the 581 ar$pro.type space (excluding 0x0080) the short form MUST be used 582 when transmitting NHRP messages. Additionally, where a protocol has 583 valid short and long forms of identification, receivers MAY choose 584 to recognize the long form. 586 ar$hopcnt 587 The Hop count indicates the maximum number of NHSs that an NHRP 588 packet is allowed to traverse before being discarded. 590 ar$pktsz 591 The total length of the NHRP packet, in octets (excluding link 592 layer encapsulation). 594 ar$chksum 595 The standard IP checksum over the entire NHRP packet (starting with 596 the fixed header). If only the hop count field is changed, the 597 checksum is adjusted without full recomputation. The checksum is 598 completely recomputed when other header fields are changed. 600 ar$extoff 601 This field identifies the existence and location of NHRP 602 extensions. If this field is 0 then no extensions exist otherwise 603 this field represents the offset from the beginning of the NHRP 604 packet (i.e., starting from the ar$afn field) of the first 605 extension. 607 ar$op.version 608 This field is set to 0x01 for NHRP version 1. 610 ar$op.type 611 This is the NHRP packet type: NHRP Next Hop Resolution Request(1), 612 NHRP Next Hop Resolution Reply(2), NHRP Registration Request(3), 613 NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge 614 Reply(6), or NHRP Error Indication(7). Use of NHRP packet Types in 615 the range 128 to 255 are reserved for research or use in other 616 protocol development and will be administered by IANA. 618 ar$shtl 619 Type & length of source NBMA address interpreted in the context of 620 the 'address family number'[6] indicated by ar$afn (e.g., 621 ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F 622 (E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl 623 must be coded appropriately (see below). 625 ar$sstl 626 Type & length of source NBMA subaddress interpreted in the context 627 of the 'address family number'[6] indicated by ar$afn (e.g., 628 ar$afn=0x000F for NSAP). When an NBMA technology has no concept of 629 a subaddress, the subaddress length is always coded ar$sstl = 0 and 630 no storage is allocated for the subaddress in the appropriate 631 mandatory part. 633 ar$shtl, ar$sstl, subnetwork layer addresses, and subnetwork layer 634 subaddresses fields are coded as follows: 636 7 6 5 4 3 2 1 0 637 +-+-+-+-+-+-+-+-+ 638 |0|x| length | 639 +-+-+-+-+-+-+-+-+ 641 The most significant bit is reserved and MUST be set to zero. The 642 second most significant bit (x) is a flag indicating whether the 643 address being referred to is in: 645 - NSAP format (x = 0). 646 - Native E.164 format (x = 1). 648 For NBMA technologies that use neither NSAP nor E.164 format 649 addresses, x = 0 SHALL be used to indicate the native form for the 650 particular NBMA technology. 652 In the case where the NBMA is ATM, if a subaddress is to be included 653 then ar$afn MUST be set to 0x000F which means that if a subaddress 654 exists then it is of type NSAP. 656 The bottom 6 bits is an unsigned integer value indicating the length 657 of the associated NBMA address in octets. If this value is zero the 658 flag x is ignored. 660 5.2.0 Mandatory Part 662 The Mandatory Part of the NHRP packet contains the operation specific 663 information (e.g., Next Hop Resolution Request/Reply, etc.) and 664 variable length data which is pertinent to the packet type. 666 5.2.0.1 Mandatory Part Format 668 Sections 5.2.1 through 5.2.6 have a very similar mandatory part. 669 This mandatory part includes a common header and zero or more Client 670 Information Entries (CIEs). Section 5.2.7 has a different format 671 which is specified in that section. 673 The common header looks like the following: 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Src Proto Len | Dst Proto Len | Flags | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Request ID | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Source NBMA Address (variable length) | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Source NBMA Subaddress (variable length) | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Source Protocol Address (variable length) | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Destination Protocol Address (variable length) | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 And the CIEs have the following format: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Code | Prefix Length | unused | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Maximum Transmission Unit | Holding Time | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Client NBMA Address (variable length) | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Client NBMA Subaddress (variable length) | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Client Protocol Address (variable length) | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 ..................... 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Code | Prefix Length | unused | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Maximum Transmission Unit | Holding Time | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Client NBMA Address (variable length) | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Client NBMA Subaddress (variable length) | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Client Protocol Address (variable length) | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 The meanings of the fields are as follows: 725 Src Proto Len 726 This field holds the length in octets of the Source Protocol 727 Address. 729 Dst Proto Len 730 This field holds the length in octets of the Destination Protocol 731 Address. 733 Flags 734 These flags are specific to the given message type and they are 735 explained in each section. 737 Request ID 738 A value which, when coupled with the address of the source, 739 provides a unique identifier for the information contained in a 740 "request" packet. This value is copied directly from an "request" 741 packet into the associated "reply". When a sender of a "request" 742 receives "reply", it will compare the Request ID and source address 743 information in the received "reply" against that found in its 744 outstanding "request" list. When a match is found then the 745 "request" is considered to be acknowledged. 747 The value is taken from a 32 bit counter that is incremented each 748 time a new "request" is transmitted. The same value MUST be used 749 when resending a "request", i.e., when a "reply" has not been 750 received for a "request" and a retry is sent after an appropriate 751 interval. 753 The NBMA address/subaddress form specified below allows combined 754 E.164/NSAPA form of NBMA addressing. For NBMA technologies without a 755 subaddress concept, the subaddress field is always ZERO length and 756 ar$sstl = 0. 758 Source NBMA Address 759 The Source NBMA address field is the address of the source station 760 which is sending the "request". If the field's length as specified 761 in ar$shtl is 0 then no storage is allocated for this address at 762 all. 764 Source NBMA SubAddress 765 The Source NBMA subaddress field is the address of the source 766 station which is sending the "request". If the field's length as 767 specified in ar$sstl is 0 then no storage is allocated for this 768 address at all. 770 Source Protocol Address 771 This is the protocol address of the station which is sending the 772 "request". This is also the protocol address of the station toward 773 which a "reply" packet is sent. 775 Destination Protocol Address 776 This is the protocol address of the station toward which a 777 "request" packet is sent. 779 Code 780 This field is message specific. See the relevant message sections 781 below. In general, this field is a NAK code; i.e., when the field 782 is 0 in a reply then the packet is acknowledging a request and if 783 it contains any other value the packet contains a negative 784 acknowledgment. 786 Prefix Length 787 This field is message specific. See the relevant message sections 788 below. In general, however, this fields is used to indicate that 789 the information carried in an NHRP the message pertains to an 790 equivalence class of internetwork layer addresses rather than just 791 a single internetwork layer address specified. All internetwork 792 layer addresses that match the first "Prefix Length" bit positions 793 for the specific internetwork layer address are included in the 794 equivalence class. 796 Maximum Transmission Unit 797 This field gives the maximum transmission unit for the relevant 798 client station. If this value is 0 then either the default MTU is 799 used or the MTU negotiated via signaling is used if such 800 negotiation is possible for the given NBMA. 802 Holding Time 803 The Holding Time field specifies the number of seconds for which 804 the Next Hop NBMA information specified in the CIE is considered to 805 be valid. Cached information SHALL be discarded when the holding 806 time expires. This field must be set to 0 on a NAK. 808 Cli Addr T/L 809 Type & length of next hop NBMA address specified in the CIE. This 810 field is interpreted in the context of the 'address family 811 number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM). 813 Cli SAddr T/L 814 Type & length of next hop NBMA subaddress specified in the CIE. 815 This field is interpreted in the context of the 'address family 816 number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes 817 the address an E.164 and the subaddress an ATM Forum NSAP address). 818 When an NBMA technology has no concept of a subaddress, the 819 subaddress is always null with a length of 0. When the address 820 length is specified as 0 no storage is allocated for the address. 822 Cli Proto Len 823 This field holds the length in octets of the Client Protocol 824 Address specified in the CIE. 826 Preference 827 This field specifies the preference for use of the specific CIE 828 relative to other CIEs. Higher values indicate higher preference. 829 Action taken when multiple CIEs have equal or highest preference 830 value is a local matter. 832 Client NBMA Address 833 This is the client's NBMA address. 835 Client NBMA SubAddress 836 This is the client's NBMA subaddress. 838 Client Protocol Address 839 This is the client's internetworking layer address specified. 841 Note that an NHS SHOULD NOT cache source information which is in an 842 NHRP message because this information could be inappropriately used 843 to set up a cut-through without doing proper filtering along a routed 844 path. Further, in the case where a distributed router exists in the 845 network, incorrect or incomplete information may be included in the 846 source information. 848 5.2.1 NHRP Next Hop Resolution Request 850 The NHRP Next Hop Resolution Request packet has a Type code of 1. Its 851 mandatory part is coded as described in Section 5.2.0.1 and the message 852 specific meanings of the fields are as follows: 854 Flags - The flags field is coded as follows: 856 0 1 857 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |Q|A|B|U| unused | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Q 863 Set if the station sending the Next Hop Resolution Request is a 864 router; clear if the it is a host. 866 A 867 This bit is set in a Next Hop Resolution Request if only 868 authoritative next hop information is desrired and is clear 869 otherwise. See the NHRP Next Hop Resolution Reply section below 870 for further details on the "A" bit and its usage. 872 B 873 Unused (clear on transmit) 875 U 876 This is the Uniqueness bit. This bit aids in duplicate address 877 detection. When this bit is set in an NHRP Resolution Request 878 and one or more entries exist in the NHS cache which meet the 879 requirements of the NHRP Resolution Request then only the CIE in 880 the NHS's cache with this bit set will be returned. Note that 881 even if this bit was set at registration time, there may still be 882 multiple CIEs that might fulfill the NHRP Resolution Request 883 because an entire subnet can be registered through use of the 884 Prefix Length in the CIE and the address of interest might be 885 within such a subnet. If the "uniqueness" bit is set and the 886 responding NHS has one or more cache entries which match the 887 request but no such cache entry has the "uniqueness" bit set, 888 then the NHRP Resolution Reply returns with a NAK code of "13 - 889 Binding Exists But Is Not Unique" and no CIE is included. If a 890 client wishes to receive non- unique Next Hop Entries, then 891 the client must have the "uniqueness" bit set to zero in its NHRP 892 Resolution Request. Note that when this bit is set in an NHRP 893 Registration Request, only a single CIE may be specified in the 894 NHRP Registration Request and that CIE must have the Prefix 895 Length field set to 0xFF. 897 Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP 898 Next Hop Resolution Request. If one is specified then that entry 899 carries the pertinent information for the client sourcing the NHRP 900 Next Hop Resolution Request. Usage of the CIE in the NHRP Next Hop 901 Resolution Request is described below: 903 Prefix Length 904 If a CIE is specified in the NHRP Next Hop Resolution Request 905 then the Prefix Length field may be used to qualify the widest 906 acceptable prefix which may be used to satisfy the NHRP Next Hop 907 Resolution Request. In the case of NHRP Next Hop Resolution 908 Request/Reply, the Prefix Length specifies the equivalence class 909 of addresses which match the first "Prefix Length" bit positions 910 of the Destination Protocol Address. If this field is set to 911 0x00 then this field MUST be ignored. If the "U" bit is set in 912 the common header then this field MUST be set to 0xFF. 914 Maximum Transmission Unit 915 This field gives the maximum transmission unit for the source 916 station. A possible use of this field in the Next Hop Resolution 917 Request packet is for the Next Hop Resolution Requester to ask 918 for a target MTU. In lieu of that usage, the CIE must be omitted. 920 All other fields in the CIE MUST be ignored and SHOULD be set to 0. 922 5.2.2 NHRP Next Hop Resolution Reply 924 The NHRP Next Hop Resolution Reply packet has a Type code of 2. CIEs 925 correspond to Next Hop Entries in an NHS's cache which match the 926 criteria in the NHRP Next Hop Resolution Request. Its mandatory part is 927 coded as described in Section 5.2.0.1. The message specific meanings of 928 the fields are as follows: 930 Flags - The flags field is coded as follows: 932 0 1 933 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 |Q|A|B|U| unused | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Q 939 Copied from the Next Hop Resolution Request. Set if the Next Hop 940 Resolution Requester is a router; clear if it is a host. 942 A 943 Set if the next hop CIE in the Next Hop Resolution Reply is 944 authoritative; clear if the Next Hop Resolution Reply is non- 945 authoritative. 947 When an NHS receives a Next Hop Resolution Request for 948 authoritative information for which it is the authoritative 949 source, it MUST respond with a Next Hop Resolution Reply 950 containing all and only those next hop CIEs which are contained 951 in the NHS's cache which both match the criteria of the Next Hop 952 Resolution Request and are authoritative cache entries. An NHS 953 is an authoritative source for a Next Hop Resolution Request if 954 the information in the NHS's cache matches the Next Hop 955 Resolution Request criteria and that information was obtained 956 through a NHRP Registration Request or through synchronization 957 with an NHS which obtained this information through a NHRP 958 Registration Request. An authoritative cache entry is one which 959 is obtained through a NHRP Registration Request or through 960 synchronization with an NHS which obtained this information 961 through a NHRP Registration Request. 963 An NHS obtains non-authoriative CIEs through promiscuous 964 listening to NHRP packets other than NHRP Registrations which are 965 directed at it. A Next Hop Resolution Request which indicates a 966 request for non-authoritative information should cause a Next Hop 967 Resolution Reply which contains all entries in the replying NHS's 968 cache (i.e., both authoritative and non-authoritative) which 969 match the criteria specified in the request. 971 B 972 Set if the association between the destination and the next hop 973 information is guaranteed to be stable for the lifetime of the 974 information (the holding time). This is the case if the Next Hop 975 protocol address identifies the destination (though it may be 976 different in value than the Destination address if the 977 destination system has multiple addresses) or if the destination 978 is not connected directly to the NBMA subnetwork but the egress 979 router to that destination is guaranteed to be stable (such as 980 when the destination is immediately adjacent to the egress router 981 through a non-NBMA interface). This information affects caching 982 strategies (see section 6.2). 984 U 985 This is the Uniqueness bit. See the NHRP Resolution Request 986 section above for details. When this bit is set only, only one 987 CIE is included since only one unique binding should exist in an 988 NHS's cache. 990 One or more CIEs are specified in the NHRP Next Hop Resolution Reply. 991 Each CIE contains NHRP next hop information which the responding NHS 992 has cached and which matches the parameters specified in the NHRP 993 Next Hop Resolution Request. If no match is found by the NHS issuing 994 the NHRP Next Hop Resolution Reply then a single CIE is enclosed with 995 the a CIE Code set appropriately (see below) and all other fields 996 MUST be ignored and SHOULD be set to 0. In order to facilitate the 997 use of NHRP by minimal client implementations, the first CIE MUST 998 contain the next hop with the highest preference value so that such 999 an implementation need parse only a single CIE. 1001 Code 1002 If this field is set to zero then this packet contains a 1003 positively acknowledged NHRP Resolution Reply. If this field 1004 contains any other value then this message contains an NHRP 1005 Resolution Reply NAK which means that an appropriate 1006 internetworking layer to NBMA address binding was not available 1007 in the responding NHS's cache. If NHRP Resolution Reply contains 1008 a Client Information Entry with a NAK Code other than 0 then it 1009 MUST NOT contain any other CIE. Currently defined NAK Codes are 1010 as follows: 1012 12 - No Internetworking Layer Address to NBMA Address Binding 1013 Exists 1015 This code states that there were absolutely no internetworking 1016 layer address to NBMA address bindings found in the responding 1017 NHS's cache. 1019 13 - Binding Exists But Is Not Unique 1021 This code states that there were one or more internetworking 1022 layer address to NBMA address bindings found in the responding 1023 NHS's cache, however none of them had the uniqueness bit set. 1025 Prefix Length 1026 In the case of NHRP Next Hop Resolution Reply, the Prefix Length 1027 specifies the equivalence class of addresses which match the 1028 first "Prefix Length" bit positions of the Destination Protocol 1029 Address. 1031 Holding Time 1032 The Holding Time specified in a CIE of an NHRP Resolution Reply 1033 is the amount of time remaining before the expiration of the 1034 client information which is cached at the replying NHS. It is 1035 not the value which was registered by the client. 1037 The remainder of the fields for the CIE for each next hop are 1038 filled out as they were defined when the next hop was registered 1039 with the responding NHS (or one of the responding NHS's 1040 synchronized servers) via the NHRP Registration Request. 1042 Load-splitting may be performed when more than one Client Information 1043 Entry is returned to a requester when equal preference values are 1044 specified. Also, the alternative addresses may be used in case of 1045 connectivity failure in the NBMA subnetwork (such as a failed call 1046 attempt in connection-oriented NBMA subnetworks). 1048 Any extensions present in the Next Hop Resolution Request packet MUST 1049 be present in the NHRP Next Hop Resolution Reply even if the 1050 extension is non-Compulsory. 1052 If an unsolicited NHRP Next Hop Resolution Reply packet is received, 1053 an Error Indication of type Invalid Next Hop Resolution Reply 1054 Received SHOULD be sent in response. 1056 5.2.3 NHRP Registration Request 1058 The NHRP Registration Request is sent from a station to an NHS to 1059 notify the NHS of the station's NBMA information. It has a Type code 1060 of 3. Each CIE corresponds to Next Hop information which is to be 1061 cached at an NHS. The mandatory part of an NHRP Registration Request 1062 is coded as described in Section 5.2.0.1. The message specific 1063 meanings of the fields are as follows: 1065 Flags - The flags field is coded as follows: 1067 0 1 1068 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 |U| unused | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 U 1074 This is the Uniqueness bit. When set in an NHRP Registration 1075 Request, this bit indicates that the registration of the protocol 1076 address is unique within the confines of the set of synchronized 1077 NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC 1078 cache. Any attempt to register a binding between the protocol 1079 address and an NBMA address when this bit is set MUST be rejected 1080 with a Code of "14 - Unique Internetworking Layer Address Already 1081 Registered" if the replying NHS already has a cache entry for the 1082 protocol address and the cache entry has the "uniqueness" bit 1083 set. A registration of a CIE's information is rejected when the 1084 CIE is returned with the Code field set to anything other than 1085 0x00. See the description of the uniqueness bit in NHRP 1086 Resolution Request section above for further details. When this 1087 bit is set only, only one CIE MAY be included in the NHRP 1088 Registration Request. 1090 Request ID 1091 The request ID has the same meaning as described in Section 1092 5.2.0.1. However, the request ID for NHRP Registrations which is 1093 maintained at each client MUST be kept in non-volatile memory so 1094 that when a client crashes and reregisters there will be no 1095 inconsistency in the NHS's database. In order to reduce the 1096 overhead associated with updating non-volatile memory, the actual 1097 updating need not be done with every increment of the Request ID 1098 but could be done, for example, every 50 or 100 increments. In 1099 this scenario, when a client crashes and reregisters it knows to 1100 add 100 to the value of the Request ID in the non-volatile memory 1101 before using the Request ID for subsequent registrations. 1103 One or more CIEs are specified in the NHRP Registration Request. 1104 Each CIE contains next hop information which a client is attempting 1105 to register with its servers. Generally, all fields in CIEs enclosed 1106 in NHRP Registration Requests are coded as described in Section 1107 5.2.0.1. However, if a station is only registering itself with the 1108 NHRP Registration Request then it MAY code the Cli Addr T/L, Cli 1109 SAddr T/L, and Cli Proto Len as zero which signifies that the client 1110 address information is to be taken from the source information in the 1111 common header (see Section 5.2.0.1). Below, further clarification is 1112 given for some fields in a CIE in the context of a NHRP Registration 1113 Request. 1115 Code 1116 This field is set to 0x00 in NHRP Registration Requests. 1118 Prefix Length 1120 This field may be used in a NHRP Registration Request to register 1121 equivalence information for the Client Protocol Address specified 1122 in the CIE of an NHRP Registration Request In the case of NHRP 1123 Registration Request, the Prefix Length specifies the equivalence 1124 class of addresses which match the first "Prefix Length" bit 1125 positions of the Client Protocol Address. If this field is set 1126 to 0x00 then this field MUST be ignored and no equivalence 1127 information is assumed (i.e., only Client Protocol Address is 1128 bound to the NBMA information). If the "U" bit is set in the 1129 common header then this field MUST be set to 0xFF. 1131 This packet is used to register a station's NHRP information with its 1132 NHSs, as configured or known through conventional routing means. 1133 NHSs may also be configured with the identities of stations that they 1134 serve. If an NHS receives an NHRP Registration Request packet which 1135 has the Destination Protocol Address field set to an address other 1136 than the NHS's own protocol address then the NHS MUST forward the 1137 packet along the routed path toward the Destination Protocol Address. 1139 It is possible that a misconfigured station will attempt to register 1140 with the wrong NHS (i.e., one that cannot serve it due to policy 1141 constraints or routing state). If this is the case, the NHS MUST 1142 reply with a NAK-ed Registration Reply of type Can't Serve This 1143 Address. 1145 If an NHS cannot serve a station due to a lack of resources, the NHS 1146 MUST reply with a NAK-ed Registration Reply of type Registration 1147 Overflow. 1149 In order to keep the registration entry from being discarded, the 1150 station MUST re-send the NHRP Registration Request packet often 1151 enough to refresh the registration, even in the face of occasional 1152 packet loss. It is recommended that the NHRP Registration Request 1153 packet be sent at an interval equal to one-third of the Holding Time 1154 specified therein. 1156 5.2.4 NHRP Registration Reply 1158 The NHRP Registration Reply is sent by an NHS to a client in response 1159 to that client's NHRP Registration Request. If the Code field of a 1160 CIE in the NHRP Registration Reply has anything other than 0 zero in 1161 it then the NHRP Registration Reply is a NAK otherwise the reply is 1162 an ACK. The NHRP Registration Reply has a Type code of 4. 1164 An NHRP Registration Reply is formed from an NHRP Registration 1165 Request by changing the type code to 4, updating the CIE Code field, 1166 and filling in the appropriate extensions if they exist. The message 1167 specific meanings of the fields are as follows: 1169 Attempts to register the information in the CIEs of an NHRP 1170 Registration Request may fail for various reasons. If this is the 1171 case then each failed attempt to register the information in a CIE of 1172 an NHRP Registration Request is logged in the associated NHRP 1173 Registration Reply by setting the CIE Code field to the appropriate 1174 error code as shown below: 1176 CIE Code 1178 0 - Successful Registration 1180 The information in the CIE was sucessfully registered with the 1181 NHS. 1183 4 - Can't Serve This Address 1185 An NHS may refuse an NHRP Registration Request attempt for 1186 administrative reasons (due to policy constraints or routing 1187 state). If so, the NHS MUST send an NHRP Registration Reply 1188 which contains a NAK code of 4. 1190 5 - Registration Overflow 1192 If an NHS cannot serve a station due to a lack of resources, 1193 the NHS MUST reply with a NAKed NHRP Registration Reply which 1194 contains a NAK code of 5. 1196 14 - Unique Internetworking Layer Address Already Registered 1197 If a client tries to register a protocol address to NBMA 1198 address binding with the uniqueness bit on and the protocol 1199 address already exists in the NHS's cache then if that cache 1200 entry also has the uniqueness bit on then this NAK Code is 1201 returned in the CIE in the NHRP Registration Reply. 1203 Due to the possible existence of asymmetric routing, an NHRP 1204 Registration Reply may not be able to merely follow the routed path 1205 back to the source protocol address specified in the common header of 1206 the NHRP Registration Reply. As a result, there MUST exist a direct 1207 NBMA level connection between the client and its NHS on which to send 1208 the NHRP Registration Reply before NHRP Registration Reply may be 1209 returned to the client. If such a connection does not exist then the 1210 NHS must setup such a connection to he client by using the source 1211 NBMA information supplied in the common header of the NHRP 1212 Registration Request. 1214 5.2.5 NHRP Purge Request 1216 The NHRP Purge Request packet is sent in order to invalidate cached 1217 information in a station. The NHRP Purge Request packet has a type 1218 code of 5. The mandatory part of an NHRP Purge Request is coded as 1219 described in Section 5.2.0.1. The message specific meanings of the 1220 fields are as follows: 1222 Flags - The flags field is coded as follows: 1224 0 1 1225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 |N| unused | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 N 1231 When set, this bit tells the receiver of the NHRP Purge Request 1232 that the requester does not expect to receive an NHRP Purge 1233 Reply. If an unsolicited NHRP Purge Reply is received by a 1234 station where that station is identified in the Source Protocol 1235 Address of the packet then that packet must be ignored. 1237 One or more CIEs are specified in the NHRP Purge Request. Each CIE 1238 contains next hop information which is to be purged from an NHS/NHC 1239 cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests 1240 are coded as described in Section 5.2.0.1. Below, further 1241 clarification is given for some fields in a CIE in the context of a 1242 NHRP Purge Request. 1244 Code 1245 This field is set to 0x00 in NHRP Purge Requests. 1247 Prefix Length 1249 In the case of NHRP Purge Requests, the Prefix Length specifies 1250 the equivalence class of addresses which match the first "Prefix 1251 Length" bit positions of the Client Protocol Address specified in 1252 the CIE. All next hop information which contains a protocol 1253 address which matches an element of this equivalence class is to 1254 be purged from the receivers cache. If this field is set to 0x00 1255 then this field MUST be ignored and no equivalence information is 1256 assumed. 1258 The Maximum Transmission Unit and Preference fields of the CIE are 1259 coded as zero. The Holding Time should be coded as zero but there 1260 may be some utility in supplying a "short" holding time to be 1261 applied to the matching next hop information before that 1262 information would be purged; this usage is for further study. The 1263 Client Protocol Address field and the Cli Proto Len field MUST be 1264 filled in. The Client Protocol Address is filled in with the 1265 protocol address to be purged from the receiving station's cache 1266 while the Cli Proto Len is set the length of the purged client's 1267 protocol address. All remaining fields in the CIE MAY be set to 1268 zero although the client NBMA information (and associated length 1269 fields) MAY be specified to narrow the scope of the NHRP Purge 1270 Request if requester desires. However, the receiver of an NHRP 1271 Purge Request may choose to ignore the Client NBMA information if 1272 it is supplied. 1274 An NHRP Purge Request packet is sent from an NHS to a station to 1275 cause it to delete previously cached information. This is done when 1276 the information may be no longer valid (typically when the NHS has 1277 previously provided next hop information for a station that is not 1278 directly connected to the NBMA subnetwork, and the egress point to 1279 that station may have changed). 1281 An NHRP Purge Request packet may also be sent from a client to an NHS 1282 with which the client had previously registered. This allows for a 1283 client to invalidate its registration with NHRP before it would 1284 otherwise expire via the holding timer. 1286 The station sending the NHRP Purge Request MAY periodically 1287 retransmit the NHRP Purge Request until either NHRP Purge Request is 1288 acknowledged or until the holding time of the information being 1289 purged has expired. Retransmission strategies for NHRP Purge 1290 Requests are a local matter. 1292 When a station receives an NHRP Purge Request, it MUST discard any 1293 previously cached information that matches the information in the 1294 CIEs. 1296 An NHRP Purge Reply MUST be returned for the NHRP Purge Request even 1297 if the station does not have a matching cache entry assuming that the 1298 "N" bit is off in the NHRP Purge Request. 1300 If the station wishes to reestablish communication with the 1301 destination shortly after receiving an NHRP Purge Request, it should 1302 make an authoritative Next Hop Resolution Request in order to avoid 1303 any stale cache entries that might be present in intermediate NHSs 1304 (See section 6.2.2.). It is recommended that authoritative Next Hop 1305 Resolution Requests be made for the duration of the holding time of 1306 the old information. 1308 5.2.6 NHRP Purge Reply 1310 The NHRP Purge Reply packet is sent in order to assure the sender of 1311 an NHRP Purge Request that all cached information of the specified 1312 type has been purged from the station sending the reply. The NHRP 1313 Purge Reply has a type code of 6. 1315 An NHRP Purge Reply is formed from an NHRP Purge Request by merely 1316 changing the type code in the request to 6. The packet is then 1317 returned to the requester after filling in the appropriate extensions 1318 if they exist. 1320 5.2.7 NHRP Error Indication 1322 The NHRP Error Indication is used to convey error indications to the 1323 sender of an NHRP packet. It has a type code of 7. The Mandatory 1324 Part has the following format: 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | Src Proto Len | Dst Proto Len | unused | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Error Code | Error Offset | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Source NBMA Address (variable length) | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Source NBMA Subaddress (variable length) | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Source Protocol Address (variable length) | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Destination Protocol Address (variable length) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Contents of NHRP Packet in error (variable length) | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Src Proto Len 1345 This field holds the length in octets of the Source Protocol 1346 Address. 1348 Dst Proto Len 1349 This field holds the length in octets of the Destination Protocol 1350 Address. 1352 Error Code 1353 An error code indicating the type of error detected, chosen from 1354 the following list: 1356 1 - Unrecognized Extension 1358 When the Compulsory bit of an extension in NHRP packet is set, 1359 the NHRP packet cannot be processed unless the extension has 1360 been processed. The responder MUST return an NHRP Error 1361 Indication of type Unrecognized Extension if it is incapable of 1362 processing the extension. However, if a transit NHS (one which 1363 is not going to generate a reply) detects an unrecognized 1364 extension, it SHALL ignore the extension. 1366 2 - Subnetwork ID Mismatch 1368 This error occurs when the current station receives an NHRP 1369 packet whose NBMA subnetwork identifier matches none of the 1370 locally known identifiers for the NBMA subnetwork on which the 1371 packet is received. 1373 3 - NHRP Loop Detected 1375 A Loop Detected error is generated when it is determined that 1376 an NHRP packet is being forwarded in a loop. 1378 6 - Protocol Address Unreachable 1380 This error occurs when a packet it moving along the routed path 1381 and it reaches a point such that the protocol address of 1382 interest is not reachable. 1384 7 - Protocol Error 1386 A generic packet processing error has occurred (e.g., invalid 1387 version number, invalid protocol type, failed checksum, etc.) 1389 8 - NHRP SDU Size Exceeded 1391 If the SDU size of the NHRP packet exceeds the MTU size of the 1392 NBMA network then this error is returned. 1394 9 - Invalid Extension 1396 If an NHS finds an extension in a packet which is inappropriate 1397 for the packet type, an error is sent back to the sender with 1398 Invalid Extension as the code. 1400 10- Invalid Next Hop Resolution Reply Received 1402 If a client receives a Next Hop Resolution Reply for a Next Hop 1403 Resolution Request which it believes it did not make then an 1404 error packet is sent to the station making the reply with an 1405 error code of Invalid Reply Received. 1407 11- Authentication Failure 1409 If a received packet fails an authentication test then this 1410 error is returned. 1412 14- Hop Count Exceeded 1414 The hop count which was specified in the Fixed Header of an 1415 NHRP message has been exceeded. 1417 Error Offset 1418 The offset in octets into the NHRP packet, starting at the NHRP 1419 Fixed Header, at which the error was detected. 1421 Source NBMA Address 1422 The Source NBMA address field is the address of the station which 1423 observed the error. 1425 Source NBMA SubAddress 1426 The Source NBMA subaddress field is the address of the station 1427 which observed the error. If the field's length as specified in 1428 ar$sstl is 0 then no storage is allocated for this address at all. 1430 Source Protocol Address 1431 This is the protocol address of the station which issued the Error 1432 packet. 1434 Destination Protocol Address 1435 This is the protocol address of the station which sent the packet 1436 which was found to be in error. 1438 An NHRP Error Indication packet SHALL NEVER be generated in response 1439 to another NHRP Error Indication packet. When an NHRP Error 1440 Indication packet is generated, the offending NHRP packet SHALL be 1441 discarded. In no case should more than one NHRP Error Indication 1442 packet be generated for a single NHRP packet. 1444 If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA 1445 and Source Protocol address fields of a transiting NHRP Error 1446 Indication packet then the NHS will quietly drop the packet and do 1447 nothing (this scenario would occur when the NHRP Error Indication 1448 packet was itself in a loop). 1450 Note that no extensions may be added to an NHRP Error Indication. 1452 5.3 Extensions Part 1454 The Extensions Part, if present, carries one or more extensions in 1455 {Type, Length, Value} triplets. Extensions are only present in a 1456 "reply" if they were present in the corresponding "request"; 1457 therefore, minimal NHRP client implementations which do not also act 1458 as an NHS and do not transmit extensions need not be able to receive 1459 extensions. The previous statement is not intended to preclude the 1460 creation of NHS-only extensions which might be added to and removed 1461 from NHRP packets by the same NHS; such extensions MUST not be 1462 propagated to clients. An implementation that is incapable of 1463 processing extensions SHALL return an NHRP Error Indication of type 1464 Unrecognized Extension when it receives an NHRP packet containing 1465 extensions. 1467 Extensions have the following format: 1469 0 1 2 3 1470 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 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 |C|u| Type | Length | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Value... | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 C 1478 "Compulsory." If clear, and the NHS does not recognize the type 1479 code, the extension may safely be ignored. If set, and the NHS 1480 does not recognize the type code, the NHRP "request" is considered 1481 to be in error. (See below for details.) 1483 u 1484 Unused and must be set to zero. 1486 Type 1487 The extension type code (see below). The extension type is not 1488 qualified by the Compulsory bit, but is orthogonal to it. 1490 Length 1491 The length in octets of the value (not including the Type and 1492 Length fields; a null extension will have only an extension header 1493 and a length of zero). 1495 When extensions exist, the extensions list is terminated by the Null 1496 TLV, having Type = 0 and Length = 0. 1498 Extensions may occur in any order, but any particular extension type 1499 (except for the vendor-private extension) may occur only once in an 1500 NHRP packet. The vendor-private extension may occur multiple times 1501 in a packet in order to allow for extensions which do not share the 1502 same vendor ID to be represented. 1504 The Compulsory bit provides for a means to add to the extension set. 1505 If the bit is set, the NHRP message cannot be properly processed by 1506 the station responding to the message (e.g., the station that would 1507 issue a Next Hop Resolution Reply in response to a Next Hop 1508 Resolution Request) without processing the extension. As a result, 1509 the responder MUST return an NHRP Error Indication of type 1510 Unrecognized Extension. If the Compulsory bit is clear then the 1511 extension can be safely ignored; however, if an ignored extension is 1512 in a "request" then it MUST be returned, unchanged, in the 1513 corresponding "reply" packet type. 1515 If a transit NHS (one which is not going to generate a "reply") 1516 detects an unrecognized extension, it SHALL ignore the extension. If 1517 the Compulsory bit is set, the transit NHS MUST NOT cache the 1518 information contained in the packet and MUST NOT identify itself as 1519 an egress router (in the Forward Record or Reverse Record 1520 extensions). Effectively, this means, if a transit NHS encounters an 1521 extension which it cannot process and which has the Compulsory bit 1522 set then that NHS MUST NOT participate in any way in the protocol 1523 exchange other than acting as a forwarding agent. 1525 Use of NHRP extension Types in the range 8192 to 16383 are reserved 1526 for research or use in other protocol development and will be 1527 administered by IANA. 1529 5.3.0 The End Of Extensions 1531 Compulsory = 1 1532 Type = 0 1533 Length = 0 1535 When extensions exist, the extensions list is terminated by the End 1536 Of Extensions/Null TLV. 1538 5.3.1 Extension with Type 1 not assigned. 1540 5.3.2 NBMA Subnetwork ID Extension 1542 Compulsory = 1 1543 Type = 2 1544 Length = variable 1546 This extension is used to carry one or more identifiers for the NBMA 1547 subnetwork. This can be used as a validity check to ensure that an 1548 NHRP packet does not leave a particular NBMA subnetwork. The 1549 extension is placed in a "request" packet with an ID value of zero. 1550 The first NHS along the routed path fills in the field with the 1551 identifier(s) for the NBMA subnetwork. 1553 Multiple NBMA Subnetwork IDs may be used as a transition mechanism 1554 while NBMA Subnetworks are being split or merged. 1556 0 1 2 3 1557 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 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | NBMA Subnetwork ID | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 ... 1563 Each identifier consists of a 32 bit globally unique value assigned 1564 to the NBMA subnetwork. This value may be chosen from the 1565 internetworking layer address space administered by the operators of 1566 the NBMA subnetwork if such an address can fit into a 32 bit field. 1567 This value is used for identification only, not for routing or any 1568 other purpose. 1570 Each NHS processing a "request" or "reply" SHALL verify these values. 1571 If the value is not zero and none of the values matches the NHS's 1572 NBMA Subnetwork ID, the NHS SHALL return an NHRP Error Indication to 1573 the entity identified in Source Protocol Address if the packet type 1574 is a "request" and to the Destination Protocol Address if the packet 1575 type is a "reply". The error indicated in this case is "Subnetwork 1576 ID Mismatch". The packet is discarded by the station sending the 1577 NHRP Error Indication. 1579 When an NHS is building a "reply" and the NBMA Subnetwork ID 1580 extension is present in the correspond "request" then the NBMA 1581 Subnetwork ID extension SHALL be copied from the "request" to the 1582 "reply". 1584 5.3.3 Responder Address Extension 1586 Compulsory = 1 1587 Type = 3 1588 Length = variable 1590 This extension is used to determine the address of the NHRP 1591 responder; i.e., the entity that generates the appropriate "reply" 1592 packet for a given "request" packet. In the case of an Next Hop 1593 Resolution Request, the station responding may be different (in the 1594 case of cached replies) than the system identified in the Next Hop 1595 field of the Next Hop Resolution Reply. Further, this extension may 1596 aid in detecting loops in the NHRP forwarding path. 1598 0 1 2 3 1599 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 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | unused | Holding Time | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | Res Addr T/L | Res SAddr T/L| Res Proto Len | unused | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Responder NBMA Address (variable length) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Responder NBMA Subaddress (variable length) | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Responder Protocol Address (variable length) | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 Holding Time 1613 The Holding Time field specifies the number of seconds for which 1614 the NBMA information is considered to be valid. Cached information 1615 SHALL be discarded when the holding time expires. 1617 Res Addr T/L 1618 Type & length of the responder NHS's NBMA address interpreted in 1619 the context of the 'address family number'[6] indicated by ar$afn 1620 (e.g., ar$afn=0x0003 for ATM). When the address length is 1621 specified as 0 no storage is allocated for the address. 1623 Res SAddr T/L 1624 Type & length of responder NHS's NBMA subaddress interpreted in the 1625 context of the 'address family number'[6] indicated by ar$afn 1626 (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the 1627 subaddress an ATM Forum NSAP address). When an NBMA technology has 1628 no concept of a subaddress, the subaddress is always null with a 1629 length of 0. When the address length is specified as 0 no storage 1630 is allocated for the address. 1632 Res Proto Len 1633 This field holds the length in octets of responding NHS's Protocol 1634 Address. 1636 Responder NBMA Address 1637 This is the NBMA address of the responding NHS. 1639 Responder NBMA SubAddress 1640 This is the NBMA subaddress of the responding NHS. 1642 Responder Protocol Address 1643 This is the Protocol Address of responding NHS. 1645 If a "requester" desires this information, the "requester" SHALL 1646 include this extension with a value of zero. Note that this implies 1647 that no storage is allocated for the Holding Time and Type/Length 1648 fields until the "Value" portion of the extension is filled out. 1650 If an NHS is generating a "reply" packet in response to a "request" 1651 containing this extension, the NHS SHALL include this extension, 1652 containing its protocol address in the "reply". If an NHS has more 1653 than one protocol address, it SHALL use the same protocol address 1654 consistently in all of the Responder Address, Forward NHS Record, and 1655 Reverse NHS Record extensions. The choice of which of several 1656 protocol address to include in this extension is a local matter. 1658 If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS 1659 contains a protocol address of that NHS in the Responder Address 1660 Extension then that NHS SHALL generate an NHRP Error Indication of 1661 type "NHRP Loop Detected" and discard the Next Hop Resolution Reply. 1663 If an NHRP Next Hop Resolution Reply packet is being returned by an 1664 intermediate NHS based on cached data, it SHALL place its own address 1665 in this extension (differentiating it from the address in the Next 1666 Hop field). 1668 5.3.4 NHRP Forward Transit NHS Record Extension 1670 Compulsory = 1 1671 Type = 4 1672 Length = variable 1674 The NHRP Forward Transit NHS record contains a list of transit NHSs 1675 through which a "request" has traversed. Each NHS SHALL append to 1676 the extension a Forward Transit NHS element (as specified below) 1677 containing its Protocol address The extension length field and the 1678 ar$chksum fields SHALL be adjusted appropriately. 1680 The responding NHS, as described in Section 5.3.3, SHALL NOT update 1681 this extension. 1683 In addition, NHSs that are willing to act as egress routers for 1684 packets from the source to the destination SHALL include information 1685 about their NBMA Address. 1687 The Forward Transit NHS element has the following form: 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | unused | Holding Time | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | NHS Addr T/L | NHS SAddr T/L| NHS Proto Len | unused | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | NHS NBMA Address (variable length) | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | NHS NBMA Subaddress (variable length) | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | NHS Protocol Address (variable length) | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 Holding Time 1704 The Holding Time field specifies the number of seconds for which 1705 the NBMA information is considered to be valid. Cached information 1706 SHALL be discarded when the holding time expires. 1708 NHS Addr T/L 1709 Type & length of the transit NHS's NBMA address interpreted in the 1710 context of the 'address family number'[6] indicated by ar$afn 1711 (e.g., ar$afn=0x0003 for ATM). When the address length is 1712 specified as 0 no storage is allocated for the address. 1714 NHS SAddr T/L 1715 Type & length of the transit NHS's NBMA subaddress interpreted in 1716 the context of the 'address family number'[6] indicated by ar$afn 1717 (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and the 1718 subaddress an ATM Forum NSAP address). When an NBMA technology has 1719 no concept of a subaddress the subaddress is always null with a 1720 length of 0. When the address length is specified as 0 no storage 1721 is allocated for the address. 1723 NHS Proto Len 1724 This field holds the length in octets of the transit NHS's Protocol 1725 Address. 1727 NHS NBMA Address 1728 This is the NBMA address of the transit NHS. 1730 NHS NBMA SubAddress 1731 This is the NBMA subaddress of the transit NHS. 1733 NHS Protocol Address 1734 This is the Protocol Address of the transit NHS. 1736 If a "requester" wishes to obtain this information, it SHALL include 1737 this extension with a length of zero. Note that this implies that no 1738 storage is allocated for the Holding Time and Type/Length fields 1739 until the "Value" portion of the extension is filled out. 1741 If an NHS has more than one Protocol address, it SHALL use the same 1742 Protocol address consistently in all of the Responder Address, 1743 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1744 which of several Protocol addresses to include in this extension is a 1745 local matter. 1747 If a "request" that is being forwarded by an NHS contains the 1748 Protocol Address of that NHS in one of the Forward Transit NHS 1749 elements then the NHS SHALL generate an NHRP Error Indication of type 1750 "NHRP Loop Detected" and discard the "request". 1752 5.3.5 NHRP Reverse Transit NHS Record Extension 1754 Compulsory = 1 1755 Type = 5 1756 Length = variable 1758 The NHRP Reverse Transit NHS record contains a list of transit NHSs 1759 through which a "reply" has traversed. Each NHS SHALL append a 1760 Reverse Transit NHS element (as specified below) containing its 1761 Protocol address to this extension. The extension length field and 1762 ar$chksum SHALL be adjusted appropriately. 1764 The responding NHS, as described in Section 5.3.3, SHALL NOT update 1765 this extension. 1767 In addition, NHSs that are willing to act as egress routers for 1768 packets from the source to the destination SHALL include information 1769 about their NBMA Address. 1771 The Reverse Transit NHS element has the following form: 1772 0 1 2 3 1773 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 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | unused | Holding Time | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | NHS Addr T/L | NHS SAddr T/L| NHS Proto Len | unused | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | NHS NBMA Address (variable length) | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | NHS NBMA Subaddress (variable length) | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | NHS Protocol Address (variable length) | 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 Holding Time 1787 The Holding Time field specifies the number of seconds for which 1788 the NBMA information is considered to be valid. Cached information 1789 SHALL be discarded when the holding time expires. 1791 NHS Addr T/L 1792 Type & length of the responding NHS's NBMA address interpreted in 1793 the context of the 'address family number'[6] indicated by ar$afn 1794 (e.g., ar$afn=0x0003 for ATM). When the address length is 1795 specified as 0 no storage is allocated for the address. 1797 NHS SAddr T/L 1798 Type & length of the responding NHS's NBMA subaddress interpreted 1799 in the context of the 'address family number'[6] indicated by 1800 ar$afn (e.g., ar$afn=0x0015 for ATM makes the address an E.164 and 1801 the subaddress an ATM Forum NSAP address). When an NBMA technology 1802 has no concept of a subaddress the subaddress is always null with a 1803 length of 0. When the address length is specified as 0 no storage 1804 is allocated for the address. 1806 NHS Proto Len 1807 This field holds the length in octets of the transit NHS's Protocol 1808 Address. 1810 NHS NBMA Address 1811 This is the NBMA address of the transit NHS. 1813 NHS NBMA SubAddress 1814 This is the NBMA subaddress of the transit NHS. 1816 NHS Protocol Address 1817 This is the Protocol Address of the transit NHS. 1819 If a "requester" wishes to obtain this information, it SHALL include 1820 this extension with a length of zero. Note that this implies that no 1821 storage is allocated for the Holding Time and Type/Length fields 1822 until the "Value" portion of the extension is filled out. 1824 If an NHS has more than one Protocol address, it SHALL use the same 1825 Protocol address consistently in all of the Responder Address, 1826 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1827 which of several Protocol addresses to include in this extension is a 1828 local matter. 1830 If a "reply" that is being forwarded by an NHS contains the Protocol 1831 Address of that NHS in one of the Reverse Transit NHS elements then 1832 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop 1833 Detected" and discard the "reply". 1835 Note that this information may be cached at intermediate NHSs; if 1836 so, the cached value SHALL be used when generating a reply. 1838 5.3.6 NHRP QoS Extension 1840 Compulsory = 0 1841 Type = 6 1842 Length = variable 1844 The NHRP QoS Extension is carried in Next Hop Resolution Request 1845 packets to indicate the desired QoS of the path to the indicated 1846 destination. This information may be used to help select the 1847 appropriate NBMA Next Hop. 1849 It may also be carried in NHRP Register Request packets to indicate 1850 the QoS to which the registration applies. 1852 The syntax and semantics of this extension are TBD; alignment with 1853 resource reservation may be useful. 1855 5.3.7 NHRP Authentication Extension 1857 Compulsory = 1 1858 Type = 7 1859 Length = variable 1861 The NHRP Authentication Extension is carried in NHRP packets to 1862 convey authentication information between NHRP speakers. The 1863 Authentication Extension may be included in any NHRP "request" or 1864 "reply". 1866 Except in the case of an NHRP Registration Request/Reply 1867 Authentication is done pairwise on an NHRP hop-by-hop basis; i.e., 1868 the authentication extension is regenerated at each hop. In the case 1869 of an NHRP Registration Request/Reply, the Authentication is checked 1870 on an end-to-end basis rather than hop-by-hop. If a received packet 1871 fails the authentication test, the station SHALL generate an Error 1872 Indication of type "Authentication Failure" and discard the packet. 1873 Note that one possible authentication failure is the lack of an 1874 Authentication Extension; the presence or absence of the 1875 Authentication Extension is a local matter. 1877 0 1 2 3 1878 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 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Authentication Type | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | | 1883 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1884 | | 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 The Authentication Type field identifies the authentication method in 1888 use. Currently assigned values are: 1890 1 - Cleartext Password 1891 2 - Keyed MD5 1893 All other values are reserved. 1895 The Authentication Data field contains the type-specific 1896 authentication information. 1898 In the case of Cleartext Password Authentication, the Authentication 1899 Data consists of a variable length password. 1901 In the case of Keyed MD5 Authentication, the Authentication Data 1902 contains the 16 byte MD5 digest of the entire NHRP packet, including 1903 the encapsulated protocol's header, with the authentication key 1904 appended to the end of the packet. The authentication key is not 1905 transmitted with the packet. 1907 Distribution of authentication keys is outside the scope of this 1908 document. 1910 5.3.8 NHRP Vendor-Private Extension 1912 Compulsory = 0 1913 Type = 8 1914 Length = variable 1916 The NHRP Vendor-Private Extension is carried in NHRP packets to 1917 convey vendor-private information or NHRP extensions between NHRP 1918 speakers. 1920 0 1 2 3 1921 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 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Vendor ID | Data.... | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 Vendor ID 1927 802 Vendor ID as assigned by the IEEE [6] 1929 Data 1930 The remaining octets after the Vendor ID in the payload are 1931 vendor-dependent data. 1933 This extension may be added to any "request" or "reply" packet and it 1934 is the only extension that may be included multiple times. If the 1935 receiver does not handle this extension, or does not match the Vendor 1936 ID in the extension then the extension may be completely ignored by 1937 the receiver. If a Vendor Private Extension is included in a 1938 "request" then is must be copied in the corresponding "reply". 1940 5.3.9 Extension with Type 9 not assigned. 1942 6. Protocol Operation 1944 In this section, we discuss certain operational considerations of 1945 NHRP. 1947 6.1 Router-to-Router Operation 1949 In practice, the initiating and responding stations may be either 1950 hosts or routers. However, there is a possibility under certain 1951 conditions that a stable routing loop may occur if NHRP is used 1952 between two routers. In particular, attempting to establish an NHRP 1953 path across a boundary where information used in route selection is 1954 lost may result in a routing loop. Such situations include the loss 1955 of BGP path vector information, the interworking of multiple routing 1956 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 1957 circumstances, NHRP should not be used. This situation can be 1958 avoided if there are no "back door" paths between the entry and 1959 egress router outside of the NBMA subnetwork. Protocol mechanisms to 1960 relax these restrictions are under investigation. 1962 In general it is preferable to use mechanisms, if they exist, in 1963 routing protocols to resolve the egress point when the destination 1964 lies outside of the NBMA subnetwork, since such mechanisms will be 1965 more tightly coupled to the state of the routing system and will 1966 probably be less likely to create loops. 1968 6.2 Cache Management Issues 1970 The management of NHRP caches in the source station, the NHS serving 1971 the destination, and any intermediate NHSs is dependent on a number 1972 of factors. 1974 6.2.1 Caching Requirements 1976 Source Stations 1978 Source stations MUST cache all received Next Hop Resolution Replies 1979 that they are actively using. They also must cache "incomplete" 1980 entries, i.e., those for which a Next Hop Resolution Request has 1981 been sent but which a Next Hop Resolution Reply has not been 1982 received. This is necessary in order to preserve the Request ID 1983 for retries, and provides the state necessary to avoid triggering 1984 Next Hop Resolution Requests for every data packet sent to the 1985 destination. 1987 Source stations MUST purge expired information from their caches. 1988 Source stations MUST purge the appropriate cached information upon 1989 receipt of an NHRP Purge Request packet. 1991 When a station has a co-resident client and NHS, the station may 1992 reply to Next Hop Resolution Requests with information which the 1993 station cached as a result of the station making its own Next Hop 1994 Resolution Requests and receiving its own Next Hop Resolution 1995 Replies as long as the station follows the rules for Transit NHSs 1996 as seen below. 1998 Serving NHSs 2000 The NHS serving the destination (the one which responds 2001 authoritatively to Next Hop Resolution Requests) SHOULD cache 2002 information about all Next Hop Resolution Requests to which it has 2003 responded if the information in the Next Hop Resolution Reply has 2004 the possibility of changing during its lifetime (so that an NHRP 2005 Purge Request packet can be sent). The NBMA information provided 2006 by the source station in the Next Hop Resolution Request may be 2007 cached for the duration of its holding time. This information is 2008 considered to be stable, since it identifies a station directly 2009 attached to the NBMA subnetwork. An example of unstable 2010 information is NBMA information derived from a routing table, where 2011 that routing table information has not been guaranteed to be stable 2012 through administrative means. 2014 Transit NHSs 2016 A Transit NHS (lying along the NHRP path between the source station 2017 and the responding NHS) may cache information contained in Next Hop 2018 Resolution Request packets that it forwards. A Transit NHS may 2019 cache information contained in Next Hop Resolution Reply packets 2020 that it forwards only if that Next Hop Resolution Reply has the 2021 Stable (B) bit set. It MUST discard any cached information whose 2022 holding time has expired. It may return cached information in 2023 response to non-authoritative Next Hop Resolution Requests only. 2025 6.2.2 Dynamics of Cached Information 2027 NBMA-Connected Destinations 2029 NHRP's most basic function is that of simple NBMA address 2030 resolution of stations directly attached to the NBMA subnetwork. 2031 These mappings are typically very static, and appropriately chosen 2032 holding times will minimize problems in the event that the NBMA 2033 address of a station must be changed. Stale information will cause 2034 a loss of connectivity, which may be used to trigger an 2035 authoritative Next Hop Resolution Request and bypass the old data. 2036 In the worst case, connectivity will fail until the cache entry 2037 times out. 2039 This applies equally to information marked in Next Hop Resolution 2040 Replies as being "stable" (via the "B" bit). 2042 This also applies equally well to source stations that are routers 2043 as well as those which are hosts. 2045 Note that the information carried in the Next Hop Resolution 2046 Request packet is always considered "stable" because it represents 2047 a station that is directly connected to the NBMA subnetwork. 2049 Destinations Off of the NBMA Subnetwork 2051 If the source of a Next Hop Resolution Request is a host and the 2052 destination is not directly attached to the NBMA subnetwork, and 2053 the route to that destination is not considered to be "stable," the 2054 destination mapping may be very dynamic (except in the case of a 2055 subnetwork where each destination is only singly homed to the NBMA 2056 subnetwork). As such the cached information may very likely become 2057 stale. The consequence of stale information in this case will be a 2058 suboptimal path (unless the internetwork has partitioned or some 2059 other routing failure has occurred). 2061 6.3 Use of the Prefix Length field of a CIE 2063 A certain amount of care needs to be taken when using the Prefix 2064 Length field of a CIE, in particular with regard to the prefix length 2065 advertised (and thus the size of the equivalence class specified by 2066 it). Assuming that the routers on the NBMA subnetwork are exchanging 2067 routing information, it should not be possible for an NHS to create a 2068 black hole by advertising too large of a set of destinations, but 2069 suboptimal routing (e.g., extra internetwork layer hops through the 2070 NBMA) can result. To avoid this situation an NHS that wants to send 2071 the Prefix Length MUST obey the following rule: 2073 The NHS examines the Network Layer Reachability Information (NLRI) 2074 associated with the route that the NHS would use to forward towards 2075 the destination (as specified by the Destination internetwork layer 2076 address in the Next Hop Resolution Request), and extracts from this 2077 NLRI the shortest address prefix such that: (a) the Destination 2078 internetwork layer address (from the Next Hop Resolution Request) 2079 is covered by the prefix, (b) the NHS does not have any routes with 2080 NLRI that forms a subset of what is covered by the prefix. The 2081 prefix may then be used in the CIE. 2083 The Prefix Length field of the CIE should be used with restraint, in 2084 order to avoid NHRP stations choosing suboptimal transit paths when 2085 overlapping prefixes are available. This document specifies the use 2086 of the prefix length only when all the destinations covered by the 2087 prefix are "stable". That is, either: 2089 (a) All destinations covered by the prefix are on the NBMA network, or 2091 (b) All destinations covered by the prefix are directly attached to 2092 the NHRP responding station. 2094 Use of the Prefix Length field of the CIE in other circumstances is 2095 outside the scope of this document. 2097 6.4 Domino Effect 2099 One could easily imagine a situation where a router, acting as an 2100 ingress station to the NBMA subnetwork, receives a data packet, such 2101 that this packet triggers an Next Hop Resolution Request. If the 2102 router forwards this data packet without waiting for an NHRP transit 2103 path to be established, then when the next router along the path 2104 receives the packet, the next router may do exactly the same - 2105 originate its own Next Hop Resolution Request (as well as forward the 2106 packet). In fact such a data packet may trigger Next Hop Resolution 2107 Request generation at every router along the path through an NBMA 2108 subnetwork. We refer to this phenomena as the NHRP "domino" effect. 2110 The NHRP domino effect is clearly undesirable. At best it may result 2111 in excessive NHRP traffic. At worst it may result in an excessive 2112 number of virtual circuits being established unnecessarily. 2113 Therefore, it is important to take certain measures to avoid or 2114 suppress this behavior. NHRP implementations for NHSs MUST provide a 2115 mechanism to address this problem. One possible strategy to address 2116 this problem would be to configure a router in such a way that Next 2117 Hop Resolution Request generation by the router would be driven only 2118 by the traffic the router receives over its non-NBMA interfaces 2119 (interfaces that are not attached to an NBMA subnetwork). Traffic 2120 received by the router over its NBMA-attached interfaces would not 2121 trigger NHRP Next Hop Resolution Requests. Such a router avoids the 2122 NHRP domino effect through administrative means. 2124 7. NHRP over Legacy BMA Networks 2126 There would appear to be no significant impediment to running NHRP 2127 over legacy broadcast subnetworks. There may be issues around 2128 running NHRP across multiple subnetworks. Running NHRP on broadcast 2129 media has some interesting possibilities; especially when setting up 2130 a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both 2131 end stations are legacy attached. This use for NHRP requires further 2132 research. 2134 8. Security Considerations 2136 As in any routing protocol, there are a number of potential security 2137 attacks possible. Plausible examples include denial-of-service 2138 attacks, and masquerade attacks using register and purge packets. 2139 The use of authentication on all packets is recommended to avoid such 2140 attacks. 2142 The authentication schemes described in this document are intended to 2143 allow the receiver of a packet to validate the identity of the 2144 sender; they do not provide privacy or protection against replay 2145 attacks. 2147 Detailed security analysis of this protocol is for further study. 2149 9. Discussion 2151 The result of an Next Hop Resolution Request depends on how routing 2152 is configured among the NHSs of an NBMA subnetwork. If the 2153 destination station is directly connected to the NBMA subnetwork and 2154 the the routed path to it lies entirely within the NBMA subnetwork, 2155 the Next Hop Resolution Replies always return the NBMA address of the 2156 destination station itself rather than the NBMA address of some 2157 egress router. On the other hand, if the routed path exits the NBMA 2158 subnetwork, NHRP will be unable to resolve the NBMA address of the 2159 destination, but rather will return the address of the egress router. 2160 For destinations outside the NBMA subnetwork, egress routers and 2161 routers in the other subnetworks should exchange routing information 2162 so that the optimal egress router may be found. 2164 In addition to NHSs, an NBMA station could also be associated with 2165 one or more regular routers that could act as "connectionless 2166 servers" for the station. The station could then choose to resolve 2167 the NBMA next hop or just send the packets to one of its 2168 connectionless servers. The latter option may be desirable if 2169 communication with the destination is short-lived and/or doesn't 2170 require much network resources. The connectionless servers could, of 2171 course, be physically integrated in the NHSs by augmenting them with 2172 internetwork layer switching functionality. 2174 References 2176 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 2177 Govindan, RFC1735. 2179 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 2181 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 2183 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 2184 and D. Piscitello, RFC 1209. 2186 [5] Protocol Identification in the Network Layer, ISO/IEC TR 2187 9577:1990. 2189 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 2191 [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, 2192 RFC1483. 2194 [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, 2195 A. Malis, D. Robinson, and R. Ullmann, RFC1356. 2197 [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and 2198 A. Malis, RFC1490. 2200 [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, 2201 Yakov Rekhter, Dilip Kandlur, RFCxxxx. 2203 Acknowledgments 2205 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 2206 Govidan of ISI for their work on NBMA ARP and the original NHRP 2207 draft, which served as the basis for this work. Russell Gardo of 2208 IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern 2209 of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of 2210 cisco, and Grenville Armitage of Bellcore should also be acknowledged 2211 for comments and suggestions that improved this work substantially. 2212 We would also like to thank the members of the ION working group of 2213 the IETF, whose review and discussion of this document have been 2214 invaluable. 2216 Authors' Addresses 2218 James V. Luciani Dave Katz 2219 Bay Networks cisco Systems 2220 3 Federal Street 170 W. Tasman Dr. 2221 Mail Stop: BL3-04 San Jose, CA 95134 USA 2222 Billerica, MA 01821 Phone: +1 408 526 8284 2223 Phone: +1 508 439 4737 Email: dkatz@cisco.com 2224 Email: luciani@baynetworks.com 2226 David Piscitello Bruce Cole 2227 Core Competence cisco Systems 2228 1620 Tuckerstown Road 170 W. Tasman Dr. 2229 Dresher, PA 19025 USA San Jose, CA 95134 USA 2230 Phone: +1 215 830 0692Phone: Phone: +1 408 526 4000 2231 Email: dave@corecom.comEmail: Email: bcole@cisco.com