idnits 2.17.1 draft-ietf-rolc-nhrp-04.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-20) 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. ** 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 216: '...st for a given destination MUST NOT be...' RFC 2119 keyword, line 243: '...P request. NHSs MUST NOT respond to a...' RFC 2119 keyword, line 273: '...ests and replies MUST NOT cross the bo...' RFC 2119 keyword, line 502: '...e Mandatory Part MUST be present, but ...' RFC 2119 keyword, line 514: '...ining NHRP packets MUST have the Don't...' (79 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental draft: draft-ietf-rolc-nbma-arp (ref. '1') ** Obsolete normative reference: RFC 1577 (ref. '3') (Obsoleted by RFC 2225) == Outdated reference: A later version (-03) exists of draft-katz-router-alert-00 ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing over Large Clouds Working Group Dave Katz 3 INTERNET-DRAFT (cisco Systems) 4 David Piscitello 5 (Core Competence, Inc.) 6 May, 1995 8 NBMA Next Hop Resolution Protocol (NHRP) 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 31 NHRP can be used by a source station (host or router) connected to a 32 Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the IP and 33 NBMA subnetwork addresses of the "NBMA next hop" towards a 34 destination station. If the destination is connected to the NBMA 35 subnetwork, then the NBMA next hop is the destination station itself. 36 Otherwise, the NBMA next hop is the egress router from the NBMA 37 subnetwork that is "nearest" to the destination station. Although 38 this document focuses on NHRP in the context of IP, the technique is 39 applicable to other internetwork layer protocols (e.g., IPX, CLNP, 40 Appletalk) as well. 42 This document is intended to be a functional superset of the NBMA 43 Address Resolution Protocol (NARP) documented in [1]. 45 Operation of NHRP as a means of establishing a transit path across an 46 NBMA subnetwork between two routers will be addressed in a separate 47 document. 49 1. Introduction 51 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 52 (a host or router), wishing to communicate over a Non-Broadcast, 53 Multi-Access (NBMA) subnetwork, to determine the IP and NBMA 54 addresses of the "NBMA next hop" toward a destination station. A 55 subnetwork can be non-broadcast either because it technically doesn't 56 support broadcasting (e.g., an X.25 subnetwork) or because 57 broadcasting is not feasible for one reason or another (e.g., an SMDS 58 multicast group or an extended Ethernet would be too large). If the 59 destination is connected to the NBMA subnetwork, then the NBMA next 60 hop is the destination station itself. Otherwise, the NBMA next hop 61 is the egress router from the NBMA subnetwork that is "nearest" to 62 the destination station. 64 An NBMA subnetwork may, in general, consist of multiple logically 65 independent IP subnets (LISs), defined in [3] and [4] as having the 66 following properties: 68 1) All members of a LIS have the same IP network/subnet number 69 and address mask. 71 2) All members within a LIS are directly connected to the same 72 NBMA subnetwork. 74 3) All members outside of the LIS are accessed via a router. 76 IP routing described in [3] and [4] only resolves the next hop 77 address if the destination station is a member of the same LIS as the 78 source station; otherwise, the source station must forward packets to 79 a router that is a member of multiple LIS's. In multi-LIS 80 configurations, hop-by-hop IP routing may not be sufficient to 81 resolve the "NBMA next hop" toward the destination station, and IP 82 packets may traverse the NBMA subnetwork more than once. 84 NHRP describes a routing method that relaxes the forwarding 85 restrictions of the LIS model. With NHRP, once the NBMA next hop has 86 been resolved, the source may either start sending IP packets to the 87 destination (in a connectionless NBMA subnetwork such as SMDS) or may 88 first establish a connection to the destination with the desired 89 bandwidth and QOS characteristics (in a connection-oriented NBMA 90 subnetwork such as ATM). 92 NHRP in its most basic form provides a simple IP-to-NBMA-address 93 binding service. This may be sufficient for hosts which are directly 94 connected to an NBMA subnetwork, allowing for straightforward 95 implementations in NBMA stations. NHRP also has the capability of 96 determining the egress point from an NBMA subnetwork when the 97 destination is not directly connected to the NBMA subnetwork and the 98 identity of the egress router is not learned by other methods (such 99 as routing protocols). Optional extensions to NHRP provide 100 additional robustness and diagnosability. 102 NHRP supports both a server-based style of deployment and a 103 ubiquitous "fabric", consisting of NHRP-capable routers. The 104 server-based approach requires a smaller number of machines (possibly 105 one) to support NHRP, but requires significantly more manual 106 configuration. 108 Address resolution techniques such as those described in [3] and [4] 109 may be in use when NHRP is deployed. ARP servers and services over 110 NBMA subnetworks may be required to support hosts that are not 111 capable of dealing with any model for communication other than the 112 LIS model, and deployed hosts may not implement NHRP but may continue 113 to support ARP variants such as those described in [3] and [4]. NHRP 114 is intended to reduce or eliminate the extra router hops required by 115 the LIS model, and can be deployed in a non-interfering manner 116 alongside existing ARP services. 118 The operation of NHRP to establish transit paths across NBMA 119 subnetworks between two routers requires additional mechanisms to 120 avoid stable routing loops, and will be described in a separate 121 document. 123 2. Overview 125 2.1 Terminology 127 The term "network" is highly overloaded, and is especially confusing 128 in the context of NHRP. We use the following terms: 130 Internetwork layer--the media-independent layer (IP in the case of 131 TCP/IP networks). 133 Subnetwork layer--the media-dependent layer underlying the 134 internetwork layer, including the NBMA technology (ATM, X.25, SMDS, 135 etc.) 137 2.2 Protocol Overview 139 In this section, we briefly describe how a source S (which 140 potentially can be either a router or a host) uses NHRP to determine 141 the "NBMA next hop" to destination D. 143 For administrative and policy reasons, a physical NBMA subnetwork may 144 be partitioned into several, disjoint "Logical NBMA subnetworks". A 145 Logical NBMA subnetwork is defined as a collection of hosts and 146 routers that share unfiltered subnetwork connectivity over an NBMA 147 subnetwork. "Unfiltered subnetwork connectivity" refers to the 148 absence of closed user groups, address screening or similar features 149 that may be used to prevent direct communication between stations 150 connected to the same NBMA subnetwork. (Hereafter, unless otherwise 151 specified, we use the term "NBMA subnetwork" to mean *logical* NBMA 152 subnetwork.) 154 Placed within the NBMA subnetwork are one or more entities that 155 implement the NHRP protocol, otherwise known as "Next Hop Servers" 156 (NHSs). Each NHS serves a set of destination hosts, which may or may 157 not be directly connected to the NBMA subnetwork. NHSs cooperatively 158 resolve the NBMA next hop within their logical NBMA subnetwork. In 159 addition to NHRP, NHSs may participate in protocols used to 160 disseminate routing information across (and beyond the boundaries of) 161 the NBMA subnetwork, and may support "classical" ARP service as well. 163 An NHS maintains a "next-hop resolution" cache, which is a table of 164 address mappings (IP-to-NBMA address). This table can be constructed 165 from information gleaned from NHRP Register packets (see Section 166 5.4), extracted from NHRP requests or replies that traverse the NHS 167 as they are forwarded, or through mechanisms outside the scope of 168 this document (examples of such mechanisms include ARP [2, 3, 4] and 169 pre-configured tables). Section 6.3 further describes cache 170 management issues. 172 A host or router that is not an NHRP server must be configured with 173 the identity of the NHS which serves it (see Configuration, Section 174 4). 176 [Note: for NBMA subnetworks that offer group or multicast addressing 177 features, it may be desirable to configure stations with a group 178 identity for NHSs, i.e., addressing information that would solicit a 179 response from "all NHSs". The means whereby a group of NHSs divide 180 responsibilities for next hop resolution are not described here.] 182 The protocol proceeds as follows. An event occurs triggering station 183 S to want to resolve the NBMA address of a path to D. This is most 184 likely to be when a data packet addressed to station D is to be 185 emitted from station S (either because station S is a host, or 186 station S is a transit router), but the address resolution could also 187 be triggered by other means (a resource reservation request, for 188 example). Station S first determines the next hop to station D 189 through normal routing processes (for a host, the next hop may simply 190 be the default router; for routers, this is the "next hop" to the 191 destination IP address). If the next hop is reachable through its 192 NBMA interface, S constructs an NHRP request packet (see Section 5.2) 193 containing station D's IP address as the (target) destination 194 address, S's own IP address as the source address (NHRP request 195 initiator), and station S's NBMA addressing information. Station S 196 may also indicate that it prefers an authoritative reply (i.e., 197 station S only wishes to receive a reply from the NHS-speaker that 198 maintains the NBMA-to-IP address mapping for this destination). 199 Station S encapsulates the NHRP request packet in an IP packet 200 containing as its destination address the IP address of its 201 configured NHS. This IP packet is emitted across the NBMA interface 202 to the NBMA address of the NHS. 204 If the NHRP request is triggered by a data packet, station S may 205 choose to dispose of the data packet while awaiting an NHRP reply in 206 one of the following ways: 208 (a) Drop the packet 209 (b) Retain the packet until the reply arrives and a more optimal 210 path is available 211 (c) Forward the packet along the routed path toward D 213 The choice of which of the above to perform is a local policy matter, 214 though option (c) is the recommended default, since it may allow data 215 to flow to the destination while the NBMA address is being resolved. 216 Note that an NHRP request for a given destination MUST NOT be 217 triggered on every packet, though periodically retrying a request is 218 permitted. 220 When the NHS receives an NHRP request, a check is made to see if it 221 "serves" station D, i.e., the NHS checks to see if there is a "next 222 hop" entry for D in its next-hop resolution cache. If the NHS does 223 not serve D, the NHS forwards the NHRP request to another NHS. 224 (Mechanisms for determining how to forward the NHRP request are 225 discussed in Section 3, Modes of Deployment.) 227 If this NHS serves D, the NHS resolves station D's NBMA address, and 228 generates a positive NHRP reply on D's behalf. (NHRP replies in this 229 scenario are always marked as "authoritative".) The NHRP reply 230 packet contains the next hop IP and NBMA address for station D and is 231 sent back to S. (Note that if station D is not on the NBMA 232 subnetwork, the next hop IP address will be that of the egress router 233 through which packets for station D are forwarded.) 235 An NHS receiving an NHRP reply may cache the NBMA next hop 236 information contained therein. To a subsequent NHRP request, this 237 NHS may respond with the cached, non-authoritative, NBMA next hop 238 information or with cached negative information, or may not be 239 allowed to respond with the cached information (see section 6.3). 240 Non-authoritative NHRP replies are distinguished from authoritative 241 replies so that if a communication attempt based on non-authoritative 242 information fails, a source station can choose to send an 243 authoritative NHRP request. NHSs MUST NOT respond to authoritative 244 NHRP requests with cached information. 246 [Note: An NHRP reply can be returned directly to the NHRP request 247 initiator, i.e., without traversing the list of NHSs that forwarded 248 the request, if all of the following criteria are satisfied: 250 (a) Direct communication is available via datagram transfer 251 (e.g., SMDS) or the NHS has an existing virtual circuit 252 connection to the NHRP request initiator or is permitted 253 to open one. 254 (b) The NHRP request initiator has not included the NHRP 255 Reverse NHS record Extension (see Section 5.7.5). 256 (c) The authentication policy in force permits direct 257 communication between the NHS and the NHRP request 258 initiator. 260 The purpose of allowing an NHS to reply directly is to reduce 261 response time. A consequence of allowing a direct reply is that 262 NHSs that would under normal circumstances be traversed by the 263 reply would not cache next hop information contained therein.] 265 The process of forwarding the NHRP request is repeated until the 266 request is satisfied, or an error occurs (e.g., no NHS in the NBMA 267 subnetwork can resolve the request.) If the determination is made 268 that station D's next hop cannot be resolved, a negative reply is 269 returned. This occurs when (a) no next-hop resolution information is 270 available for station D from any NHS, or (b) an NHS is unable to 271 forward the NHRP request (e.g., connectivity is lost). 273 NHRP requests and replies MUST NOT cross the borders of a logical 274 NBMA subnetwork (an explicit NBMA subnetwork identifier may be 275 included as an extension in the NHRP request, see section 5.7.2). 276 Thus, IP traffic out of and into a logical NBMA subnetwork always 277 traverses an IP router at its border. Internetwork layer filtering 278 can then be implemented at these border routers. 280 NHRP optionally provides a mechanism to reply with aggregated NBMA 281 next hop information. Suppose that router X is the NBMA next hop 282 from station S to station D. Suppose further that X is an egress 283 router for all stations sharing an IP address prefix with station D. 284 When an NHRP reply is generated in response to a request, the 285 responder may augment the IP address of station D with a bit count 286 defining this prefix (see Section 5.7.1). A subsequent (non- 287 authoritative) NHRP request for some destination that shares an IP 288 address prefix with D may be satisfied with this cached information. 289 See section 6.3 regarding caching issues. 291 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 292 (e.g., X.25 closed user group facility, or SMDS address screens), as 293 well as to provide loop detection and diagnostic capabilities, NHRP 294 optionally incorporates a "Route Record" in requests and replies (see 295 Sections 5.7.4 and 5.7.5). The Route Record extensions contain the 296 internetwork (and subnetwork layer) addresses of all intermediate 297 NHSs between source and destination (in the forward direction) and 298 between destination and source (in the reverse direction). When a 299 source station is unable to communicate with the responder (e.g., an 300 attempt to open an SVC fails), it may attempt to do so successively 301 with other subnetwork layer addresses in the Route Record until it 302 succeeds (if authentication policy permits such action). This 303 approach can find a suitable egress point in the presence of 304 subnetwork-layer filtering (which may be source/destination 305 sensitive, for instance, without necessarily creating separate 306 logical NBMA subnetworks) or subnetwork-layer congestion (especially 307 in connection-oriented media). 309 NHRP messages, with the exception of Purge packets, are sent 310 unreliably. NHRP requests should be retransmitted periodically until 311 either a Reply or an Error packet is received. 313 3. Modes of Deployment 315 NHRP supports two deployment modes of operation: "server" and 316 "fabric" modes. The two modes differ only in the way NHRP packets 317 are propagated, which is driven by differences in configuration. 319 It is desirable that hosts attached directly to the NBMA subnetwork 320 have no knowledge of whether NHRP is deployed in "server" or "fabric" 321 modes, so that a change in deployment strategy can be done within a 322 single administration, transparently to hosts. For this reason, host 323 configuration is invariant between the two cases. Note that 324 irrespective of which mode is deployed, NHRP clients must nominally 325 be configured with the NBMA (and IP) address of at least one NHS. In 326 practice, a host's default router should also be its NHS. 328 Server Mode 330 In "server" mode, the expectation is that a small number of NHSs 331 will be fielded in an NBMA subnetwork. This may be appropriate in 332 subnetworks containing routers that do not support NHRP, or 333 subnetworks that have large numbers of directly-attached hosts (and 334 relatively few routers). Server mode assumes that NHRP is very 335 loosely coupled with IP routing, and that the path taken by NHRP 336 requests has little to do with the path taken by IP data packets 337 routed to the desired destination. Note that in server mode the 338 NHSs need not be routers, since they will not be required to 339 forward transit data packets. 341 [Note: This is the likely scenario for initial deployment of NHRP. 342 It is also likely that single and Multi-LIS configurations using 343 either group-addressed ARP (in the case of SMDS) or ARP servers (in 344 the case of ATM or SMDS) may already be in place.] 346 Server mode uses static configuration of NHS identity. The client 347 station must be configured with the IP address of one or more NHSs, 348 and there must be a path to that NHS (either directly, in which 349 case the NHS's NBMA address must be known, or indirectly, through a 350 router whose NBMA address is known). If there are multiple NHSs, 351 they must be configured with each others' addresses, the identities 352 of the destinations that each of them serves, and optionally a 353 logical NBMA subnetwork identifier. (This static configuration 354 requirement, which may involve authentication as well as addressing 355 information, tends to limit such deployments to a very small number 356 of NHSs.) 358 If the NBMA subnetwork offers a group addressing or multicast 359 feature, the client (station) may be configured with a group 360 address assigned to the group of next-hop servers. The client 361 might then submit NHRP requests to the group address, eliciting a 362 response from one or more NHSs, depending on the response strategy 363 selected. Note that the constraints described in Section 2 364 regarding direct replies may apply. 366 The servers can also be deployed with the group or multicast 367 address of their peers, and an NHS might use this as a means of 368 forwarding NHRP requests it cannot satisfy to its peers. This 369 might elicit a response (to the NHS) from one or more NHSs, 370 depending on the response strategy. The NHS would then forward the 371 NHRP reply to the NRHP request originator. The purpose of using 372 group addressing or a similar multicast mechanism in this scenario 373 would be to eliminate the need to preconfigure each NHS in a 374 logical NBMA subnetwork with both the individual identities of 375 other NHSs as well as the destinations they serve. It reduces the 376 number of NHSs that might be traversed to process an NHRP request 377 (in those configurations where NHSs either respond or forward via 378 the multicast, only two NHSs would be traversed), and allows the 379 NHS that serves the NHRP request originator to cache next hop 380 information associated with the reply (again, within the 381 constraints described in Section 2). 383 The NHRP request packet's destination IP address is set by the 384 source station to the first-hop NHS's IP address. If the addressed 385 NHS does not serve the destination, the NHRP request is forwarded 386 to the IP address of the NHS that serves the destination. 388 The responding NHS uses the source address from within the NHRP 389 packet (not the source address of the IP packet) as the IP 390 destination of the NHRP reply. 392 Note that, in many cases, NHSs deployed in Server Mode are unlikely 393 to be able to resolve the next hop of destination that lies outside 394 of the NBMA subnetwork, since doing so requires routing knowledge 395 that is only provided by certain protocols (Link State routing 396 protocols, for example); with many routing protocols, only the 397 egress router itself knows that it is the egress router. The 398 identity of the egress router may be provided by a server if such 399 information is very static; in practical terms the egress router 400 can only be guaranteed to be fixed if static routing is in use, or 401 there is only one egress router. If the identity of egress routers 402 cannot be determined, then the NHSs can only provide information 403 about destinations directly attached to the NBMA subnetwork. 405 Fabric Mode 407 In "fabric" mode, it is expected that NHRP-capable routers are 408 ubiquitous throughout the NBMA subnetwork, and that NHSs acquire 409 knowledge about destinations other NHSs serve as a direct 410 consequence of participating in intradomain and interdomain routing 411 protocol exchange. In particular, the NHS serving a particular 412 destination must lie along the routed path to that destination. In 413 practice, this means that all egress routers must double as NHSs 414 serving the destinations beyond them, and that hosts on the NBMA 415 subnetwork are served by routers that double as NHSs. 417 Fabric mode leverages a routed infrastructure that "overlays" the 418 NBMA subnetwork. The source station passes the NHRP request to the 419 router which serves as the next hop toward the destination. Each 420 router in turn forwards the NHRP request toward the destination. 421 Eventually, the NHRP request arrives at a router that is acting as 422 an NHS serving the destination (or the destination itself, if it is 423 an NHRP-speaker), which generates the NHRP reply. 425 If the source station is a host, it sets the IP destination address 426 of the NHRP request to the first-hop NHS/router (so that hosts 427 needn't know the mode in which the subnetwork is running). If the 428 source station is a router, the destination IP address may be set 429 either to the next-hop router or to the ultimate destination being 430 resolved. Each NHS/router examines the NHRP request packet on its 431 way toward the destination, optionally modifying it on the way 432 (such as updating the Forward Record extension). The Router Alert 433 option [5] is added by the first NHS in order to ensure that 434 NHS/routers along the path process the packet, even though it may 435 be addressed to the ultimate destination. 437 If an NHS/router receives an NHRP packet addressed to itself to 438 which it cannot reply (because it does not serve the destination 439 directly), it will forward the NHRP request with the destination IP 440 address set to the ultimate destination (thus allowing invariant 441 host behavior). Eventually, the NHRP packet will arrive at the 442 NHS/router that serves the destination (which will return a 443 positive NHRP reply) or it will arrive at a NHS/router that has no 444 route to the destination (which will return a negative NHRP reply), 445 or it may arrive at a NHS/router that cannot reach the NHS that 446 serves the destination due to a loss of reachability among the NHSs 447 (in which case the router will return a negative NHRP reply). 449 The procedural difference between server mode and fabric mode is 450 reduced to deciding how to update the destination address in the IP 451 packet carrying the NHRP request. 453 Note that addressing the NHRP request to the ultimate destination 454 allows for subnetworks that do not have NHSs deployed in all 455 routers; typically a very large NBMA subnetwork might only deploy 456 NHSs in egress routers, and not in transit routers. 458 4. Configuration 460 Stations 462 To participate in NHRP, a station connected to an NBMA subnetwork 463 should be configured with the IP and NBMA address(es) of its NHS(s) 464 (alternatively, it should be configured with a means of acquiring 465 them, i.e., the group address that members of a NHS group use for 466 the purpose of address or next-hop resolution.) The NHS(s) may be 467 physically located on the stations's default or peer routers, so 468 their addresses may be obtained from the station's IP forwarding 469 table. If the station is attached to several subnetworks 470 (including logical NBMA subnetworks), the station should also be 471 configured to receive routing information from its NHS(s) and peer 472 routers so that it can determine which IP networks are reachable 473 through which subnetworks. 475 Next Hop Servers 477 An NHS is configured with its own identity, a set of IP address 478 prefixes that correspond to the IP addresses of the stations it 479 serves, a logical NBMA subnetwork identifier (see Section 5.7.2), 480 and in the case of "server" mode, the identities of other NHSs in 481 the same logical NBMA subnetwork. If a served station is attached 482 to several subnetworks, the NHS may also need to be configured to 483 advertise routing information to such stations. 485 If an NHS acts as an egress router for stations connected to other 486 subnetworks than the NBMA subnetwork, the NHS must, in addition to 487 the above, be configured to exchange routing information between 488 the NBMA subnetwork and these other subnetworks. 490 In all cases, routing information is exchanged using conventional 491 intra-domain and/or inter-domain routing protocols. 493 The NBMA addresses of the stations served by the NHS may be learned 494 via NHRP Register packets or manual configuration. 496 5. Packet Formats 498 This section describes the format of NHRP packets. 500 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 501 Extensions Part. The Fixed Part is common to all NHRP packet types. 502 The Mandatory Part MUST be present, but varies depending on packet 503 type. The Extensions Part also varies depending on packet type, and 504 need not be present. 506 The length of the Fixed Part is fixed at 8 octets. The length of the 507 Mandatory Part is carried in the Fixed Part. The length of the 508 Extensions Part is implied by the total packet length (Internet 509 datagram total length minus IP header length minus NHRP fixed part 510 length minus NHRP mandatory part length). 512 NHRP packets are carried in IP packets as protocol type 54 (decimal). 513 NHSs may increase the size of an NHRP packet as a result of extension 514 processing. IP datagrams containing NHRP packets MUST have the Don't 515 Fragment bit set. 517 Fields marked "unused" MUST be set to zero on transmission, and 518 ignored on receipt. 520 Most packet types have both internetwork layer protocol-independent 521 fields and protocol-specific fields. The protocol-independent fields 522 always come first in the packet, and the Protocol ID field qualifies 523 the format of the protocol-specific fields. The protocol-specific 524 fields defined in this document are for IPv4 only; formats of 525 protocol-specific fields for other protocols are for further study. 527 The protocol ID field in general will contain the Ethertype value for 528 the protocol (see [6]). For protocols that do not have an assigned 529 Ethertype, this field will in general contain the Network Layer 530 Protocol Identifier (NLPID, [7]) value for the protocol (this is 531 guaranteed to not cause collisions since the NLPID cannot be greater 532 than 255 decimal, and the Ethertype cannot be less than 1500 533 decimal). 535 5.1 NHRP Fixed Header 537 The NHRP Fixed Header is present in all NHRP packets. It contains 538 the basic information needed to parse the rest of the packet. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Version | Hop Count | Checksum | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type | Unused | Mandatory Part Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Version 549 The NHRP version number. Currently this value is 1. 551 Hop Count 552 The Hop count indicates the maximum number of NHSs that an NHRP 553 packet is allowed to traverse before being discarded. 555 Checksum 556 The standard IP checksum over the entire NHRP packet (starting with 557 the fixed header). If only the hop count field is changed, the 558 checksum is adjusted without full recomputation. The checksum is 559 completely recomputed when other header fields are changed. 561 Type 562 The NHRP packet type: Request, Response, Register, Purge, or Error 563 Indication (see below). 565 Mandatory Part Length 566 The length in octets of the Mandatory Part. This length does not 567 include the Fixed Header. 569 5.2 NHRP Request 571 The NHRP Request packet has a Type code of 1. The Mandatory Part has 572 the following format: 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Q|S|A|P|B| Unused | Protocol ID | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Request ID | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 (IPv4-Specific) 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Destination IP address | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Source IP address | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Holding Time | Address Type | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Unused | NBMA Length | NBMA Address (variable length)| 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Q 594 Set if the Requestor is a router; clear if the requestor is a 595 host. 597 S 598 Unused (zero on transmit) 600 A 601 A response to an NHRP request may contain cached information. If 602 an authoritative answer is desired, then this bit ("Authoritative") 603 should be set. If non-authoritative (cached) information is 604 acceptable, this bit should be clear. 606 P 607 Unused (zero on transmit) 609 B 610 Unused (zero on transmit) 612 Protocol ID 613 Specifies the internetwork layer protocol for which we are 614 obtaining routing information. This value also qualifies the 615 structure of the remainder of the Mandatory Part. For IPv4, the 616 Protocol ID is hexadecimal 800 (decimal 2048). Protocol ID values 617 for other internetwork layer protocols are for future study. 619 Request ID 620 A value which, when coupled with the address of the source, 621 provides a unique identifier for the information contained in a 622 Request and its associated Reply, and any subsequent Purge. This 623 value can be used by the source to aid in matching requests with 624 replies. This value could also be sent across a virtual circuit 625 (in SVC environments) to aid in matching NHRP transactions with 626 virtual circuits (this use is for further study). 628 The value is taken from a 32 bit counter that is incremented each 629 time a new NHRP request is transmitted. The same value MUST be 630 used when sending another request for the same destination when a 631 previous request is still active or pending, i.e., when 632 retransmitting a request because a reply was not received, or when 633 refreshing an existing entry to avoid holding timer expiration. A 634 new value MUST be used when sending a request when no cache entry 635 is present, or a previous cache entry was deleted for any reason. 637 Destination and Source IP Addresses 638 Respectively, these are the IP addresses of the station for which 639 the NBMA next hop is desired, and the NHRP request initiator. 641 Source Holding Time, Address Type, NBMA Length, and NBMA Address 642 The Holding Time field specifies the number of seconds for which 643 the source NBMA information is considered to be valid. Cached 644 information SHALL be discarded when the holding time expires. 646 The Address Type field specifies the type of NBMA address 647 (qualifying the NBMA address). Possible address types are listed 648 in [6]. 650 The NBMA length field is the length of the NBMA address of the 651 source station in bits. The NBMA address field itself is zero- 652 filled to the nearest 32-bit boundary. 654 5.3 NHRP Reply 656 The NHRP Reply packet has a type code of 2. The Mandatory Part has 657 the following format: 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |Q|S|A|P|B| Unused | Protocol ID | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Request ID | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 (IPv4-Specific) 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Destination IP address | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Source IP address | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Next-hop IP address | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Holding Time | Address Type | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Preference | NBMA Length | NBMA Address (variable length)| 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 ... 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Next-hop IP address | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Holding Time | Address Type | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Preference | NBMA Length | NBMA Address (variable length)| 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Q 691 Copied from the NHRP Request. Set if the Requestor is a router; 692 clear if the requestor is a host. 694 S 695 Set if the next hop identified in the reply is a router; clear if 696 the next hop is a host. 698 A 699 Set if the reply is authoritative; clear if the reply is non- 700 authoritative. 702 P 703 Set if the reply is positive; clear if the reply is negative. 705 B 706 Set if the association between the destination and the next hop 707 information is guaranteed to be stable for the lifetime of the 708 information (the holding time). This is the case if the Next-hop 709 IP address identifies the destination (though it may be different 710 in value than the Destination address if the destination system has 711 multiple addresses) or if the destination is not connected directly 712 to the NBMA subnetwork but the egress router to that destination is 713 guaranteed to be stable (such as when the destination is 714 immediately adjacent to the egress router through a non-NBMA 715 interface). This information affects cacheing strategies (see 716 section 6.3). 718 An NHS is not allowed to reply to an NHRP request for authoritative 719 information with cached information, but may do so for an NHRP 720 Request which indicates a request for non-authoritative information. 721 An NHS may reply to an NHRP request for non-authoritative information 722 with authoritative information. 724 Protocol ID 725 Specifies the internetwork layer protocol for which we are 726 obtaining routing information. This value also qualifies the 727 structure of the remainder of the Mandatory Part. For IPv4, the 728 Protocol ID is hexadecimal 800 (decimal 2048). Protocol ID values 729 for other internetwork layer protocols are for future study. 731 Request ID 732 Copied from the NHRP Request. 734 Destination IP Address 735 The address of the target station (copied from the corresponding 736 NHRP Request). 738 Source IP Address 739 The address of the initiator of the request (copied from the 740 corresponding NHRP Request). 742 Next-hop entry 743 A Next-hop entry consists of the following fields: a 32-bit Next- 744 hop IP Address, a 16-bit Holding Time, an 8-bit Preference, an 8- 745 bit Address Type, an 8-bit NBMA Length, and an NBMA Address whose 746 length is the value of the NBMA length field. 748 The Next-hop IP Address specifies the IP address of the next hop. 749 This will be the address of the destination host if it is directly 750 attached to the NBMA subnetwork, or the egress router if it is not 751 directly attached. 753 The Holding Time field specifies the number of seconds for which 754 the associated Next-hop entry information is considered to be 755 valid. Cached information SHALL be discarded when the holding time 756 expires. (Holding time is to be specified for both positive and 757 negative replies). 759 The Address Type field specifies the type of NBMA address 760 (qualifying the NBMA address). Possible address types are listed 761 in [6]. 763 The Preference field specifies the preference of the Next-hop 764 entry, relative to other Next-hop entries in this NHRP Reply 765 packet. Higher values indicate more preferable Next-hop entries. 766 Action taken when multiple next-hop entries have the highest 767 preference value is a local matter. 769 The NBMA length field specifies the length of the NBMA address of 770 the destination station in bits. The NBMA address field itself is 771 zero-filled to the nearest 32-bit boundary. For negative replies, 772 the Holding Time field is relevant; however, the preference, 773 Address Type, and NBMA length fields MUST be zero, and the NBMA 774 Address SHALL NOT be present. 776 There may be multiple Next-hop entries returned in the reply (as 777 implied by the Mandatory Part Length). The preference values are 778 used to select the preferred entry. The same next-hop IP address 779 may be associated with multiple NBMA addresses. Load-splitting may 780 be performed over the addresses, given equal preference values, and 781 the alternative addresses may be used in case of connectivity 782 failure in the NBMA subnetwork (such as a failed call attempt in 783 connection-oriented NBMA subnetworks). 785 If extensions were present in the NHRP Request packet, all of these 786 extensions MUST be present in the NHRP Reply. No additional 787 extensions may be added to the reply that were not present in the 788 request. 790 5.4 NHRP Register 792 The NHRP Register packet is sent from a station to an NHS to notify 793 the NHS of the station's NBMA address. It has a Type code of 3. The 794 Mandatory Part has the following format: 796 0 1 2 3 797 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 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Unused | Protocol ID | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 (IPv4-Specific) 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Source IP address | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Holding Time | Address Type | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Unused | NBMA Length | NBMA Address (variable length)| 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Protocol ID 812 Specifies the internetwork layer protocol for which we are 813 obtaining routing information. This value also qualifies the 814 structure of the remainder of the Mandatory Part. For IPv4, the 815 Protocol ID is hexadecimal 800 (decimal 2048). Protocol ID values 816 for other internetwork layer protocols are for future study. 818 Source IP Address 819 The IP address of the station wishing to register its NBMA address 820 with an NHS. 822 Source Holding Time, Address Type, NBMA Length, and NBMA Address 823 The Holding Time field specifies the number of seconds for which 824 the source NBMA information is considered to be valid. Cached 825 information SHALL be discarded when the holding time expires. 827 The Address Type field specifies the type of NBMA address 828 (qualifying the NBMA address). Possible address types are listed 829 in [6]. 831 The NBMA length field is the length of the NBMA address of the 832 source station in bits. The NBMA address itself is zero-filled to 833 the nearest 32-bit boundary. 835 This packet is used to register a station's IP and NBMA addresses 836 with its configured NHS. This allows static configuration 837 information to be reduced; the NHSs need not be configured with the 838 identities of all of the stations that they serve. 840 It is possible that a misconfigured station will attempt to register 841 with the wrong NHS (i.e., one that cannot serve it due to policy 842 constraints or routing state). If this is the case, the NHS MUST 843 reply with an Error Indication of type Can't Serve This Address. 845 If an NHS cannot serve a station due to a lack of resources, the NHS 846 MUST reply with an Error Indication of type Registration Overflow. 848 In order to keep the registration entry from being discarded, the 849 station MUST resend the Register packet often enough to refresh the 850 registration, even in the face of occasional packet loss. It is 851 recommended that the Registration packet be sent at an interval equal 852 to one-third of the Holding Time specified therein. 854 5.5 NHRP Purge 856 The NHRP Purge packet has a type code of 4. The Mandatory Part has 857 the following format: 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 |A| Unused | Protocol ID | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Request ID | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 (IPv4-Specific) 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Source IP address | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 A 873 Clear if this is a purge request, set if this is an 874 acknowledgement. 876 Protocol ID 877 Specifies the internetwork layer protocol for which we are 878 obtaining routing information. This value also qualifies the 879 structure of the remainder of the Mandatory Part. For IPv4, the 880 Protocol ID is hexadecimal 800 (decimal 2048). Protocol ID values 881 for other internetwork layer protocols are for future study. 883 Request ID 884 Copied from the corresponding NHRP Request. This is used by the 885 station receiving the purge to identify which cache entry to purge, 886 and by the NHS receiving the acknowledgement to match the 887 acknowledgement with the Purge request. 889 Source IP Address 890 The address of the initiator of the request (copied from the 891 corresponding NHRP Request). Used by the NHS receiving the 892 acknowledgement to match the acknowledgement with the Purge 893 request. 895 An NHRP Purge request packet is sent from an NHS to a station to 896 cause it to delete previously cached information. This is done when 897 the information may be no longer valid (typically when the NHS has 898 previously provided next hop information for a destination that is 899 not directly connected to the NBMA subnetwork, and the egress point 900 to that destination may have changed). 902 The IP destination address of the packet containing the Purge request 903 is set to the Source IP address from the original Request packet. 905 The NHS sending the NHRP Purge request MUST periodically retransmit 906 the request until it is acknowledged, or until the holding time of 907 the information being purged has expired. Retransmission strategies 908 are for further investigation. 910 When a station receives an NHRP Purge request, it MUST discard any 911 previous cached information that matches the Request ID. It MUST 912 then acknowledge the Purge request by setting the Acknowledgement (A) 913 bit and returning the Purge request to the sender. The IP 914 destination address of the Purge acknowledgement MUST be set to the 915 IP source address of the Purge request. 917 An acknowledgement MUST be returned for the Purge request even if the 918 station does not have a cache entry with a matching Request ID. 920 If the station wishes to reestablish communication with the 921 destination shortly after receiving a Purge request, it should make 922 an authoritative request in order to avoid any stale cache entries 923 that might be present in intermediate NHSs. (See section 6.3.2.) It 924 is recommended that authoritative requests be made for the duration 925 of the holding time of the old information. 927 5.6 NHRP Error Indication 929 The NHRP Error Indication is used to convey error indications to the 930 initiator of an NHRP Request packet. It has a type code of 5. The 931 Mandatory Part has the following format: 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Error Code | Error Offset | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | | 939 +-+-+-+-+-+-+-+ Contents of NHRP Packet in error +-+-+-+-+-+-+-+ 940 | | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 Error Code 944 An error code indicating the type of error detected, chosen from 945 the following list: 947 1 - Unrecognized Extension 948 2 - Subnetwork ID Mismatch 949 3 - NHRP Loop Detected 950 4 - Can't Serve This Address 951 5 - Registration Overflow 952 6 - Server Unreachable 953 7 - Protocol Error 954 8 - NHRP fragmentation failure 956 Error Offset 957 The offset in octets into the original NHRP packet, starting at the 958 NHRP Fixed Header, at which the error was detected. 960 The destination IP address of an NHRP Error Indication SHALL be set 961 to the IP address of the initiator of the original NHRP Request (as 962 extracted from the NHRP Request or NHRP Reply). 964 An Error Indication packet SHALL NEVER be generated in response to 965 another Error Indication packet. When an Error Indication packet is 966 generated, the offending NHRP packet SHALL be discarded. In no case 967 should more than one Error Indication packet be generated for a 968 single NHRP packet. 970 5.7 Extensions Part 972 The Extensions Part, if present, carries one or more extensions in 973 {Type, Length, Value} triplets. Extensions are only present in a 974 Reply if they were present in the corresponding Request; therefore, 975 minimal NHRP station implementations that do not act as an NHS and do 976 not transmit extensions need not be able to receive them. An 977 implementation that is incapable of processing extensions SHALL 978 return an Error Indication of type Unrecognized Extension when it 979 receives an NHRP packet containing extensions. 981 Extensions are typically protocol-specific, as noted. 983 Extensions have the following format: 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |D| Type | Length | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Value... | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 D 994 "Discretionary." If set, and the NHS does not recognize the type 995 code, the extension may safely be ignored. If clear, and the NHS 996 does not recognize the type code, the NHRP request is considered in 997 error. (See below for details.) 999 Type 1000 The extension type code (see below). The extension type is not 1001 qualified by the Discretionary bit, but is orthogonal to it. 1003 Length 1004 The length in octets of the value (not including the Type and 1005 Length fields; a null extension will have only an extension header 1006 and a length of zero). 1008 Each extension is padded with zero octets to a 32 bit boundary. This 1009 padding is not included in the Length field. 1011 Extensions may occur in any order, but any particular extension type 1012 may occur only once in an NHRP packet. 1014 The Discretionary bit provides for a means to add to the extension 1015 set. If the bit is clear, the NHRP request cannot be satisfied 1016 unless the extension is processed, so the responder MUST return an 1017 Error Indication of type Unrecognized Extension. If the bit is set, 1018 the extension can be safely ignored, though unrecognized extensions 1019 so ignored that were received in an NHRP Request packet MUST be 1020 returned unchanged in the corresponding NHRP Reply. 1022 If a transit NHS (one which is not going to generate a reply) detects 1023 an unrecognized extension, it SHALL ignore the extension. If the 1024 Discretionary bit is clear, the transit NHS MUST NOT cache the 1025 information (in the case of a reply) and MUST NOT identify itself as 1026 an egress router (in the Forward Record or Reverse Record 1027 extensions). Effectively, this means that a transit NHS that 1028 encounters an extension that it cannot process and determines that 1029 the Discretionary bit is clear MUST NOT participate in any way in the 1030 protocol exchange, other than acting as a forwarding agent for the 1031 request. 1033 5.7.1 Destination Prefix Extension (IPv4-Specific) 1035 Discretionary = 1 1036 Type = 1 1037 Length = 1 1039 This extension is used to indicate that the information carried in an 1040 NHRP Reply pertains to an equivalence class of destinations rather 1041 than just the destination IP address specified in the request. All 1042 addresses that match the IP address prefix defined by the prefix 1043 length are part of the equivalence class. 1045 0 1046 0 1 2 3 4 5 6 7 1047 +-+-+-+-+-+-+-+-+ 1048 | Prefix Length | 1049 +-+-+-+-+-+-+-+-+ 1051 If an initiator would like to receive this equivalence information, 1052 it SHALL add this extension to the NHRP Request with a value of 32. 1053 The responder SHALL copy the extension to the NHRP Reply and modify 1054 the prefix length appropriately. 1056 5.7.2 NBMA Subnetwork ID Extension (Protocol-Independent) 1058 Discretionary = 0 1059 Type = 2 1060 Length = variable 1062 This extension is used to carry one or more identifiers for the NBMA 1063 subnetwork. This can be used as a validity check to ensure that the 1064 request does not leave a particular NBMA subnetwork. The extension 1065 is placed in an NHRP Request packet by the initiator with an ID value 1066 of zero; the first NHS fills in the field with the identifier(s) for 1067 the NBMA subnetwork. 1069 Multiple NBMA Subnetwork IDs may be used as a transition mechanism 1070 while NBMA Subnetworks are being split or merged. 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | NBMA Subnetwork ID | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 ... 1079 Each identifier consists of a 32 bit globally unique value assigned 1080 to the NBMA subnetwork. This value should be chosen from the IP 1081 address space administered by the operators of the NBMA subnetwork. 1082 This value is used for identification only, not for routing or any 1083 other purpose. 1085 Each NHS processing an NHRP Request SHALL verify these values. If 1086 none of the values matches the NHS's NBMA Subnetwork ID, the NHS 1087 SHALL return an Error Indication of type "Subnetwork ID Mismatch" and 1088 discard the NHRP Request. 1090 When an NHS is building an NHRP Reply and the NBMA Subnetwork ID 1091 extension is present in the NHRP Request, the NBMA Subnetwork ID 1092 extension SHALL be copied from the Request to the Reply, including 1093 all values carried therein. 1095 Each NHS processing an NHRP Reply SHALL verify the values carried in 1096 the NBMA Subnetwork ID extension, if present. If none of the values 1097 matches the NHSs NBMA Subnetwork ID, the NHS SHALL return an Error 1098 Indication of type "Subnetwork ID Mismatch" and discard the NHRP 1099 Reply. 1101 5.7.3 Responder Address Extension (IPv4-Specific) 1103 Discretionary = 0 1104 Type = 3 1105 Length = 4 1107 This extension is used to determine the IP address of the NHRP 1108 Responder, that is, the entity that generates the NHRP Reply packet. 1109 The intent is to identify the entity responding to the request, which 1110 may be different (in the case of cached replies) than the system 1111 identified in the Next-hop field of the reply, and to aid in 1112 detecting loops in the NHRP forwarding path. 1114 0 1 2 3 1115 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 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Responder's IP Address | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 If a requestor desires this information, it SHALL include this 1121 extension, with a value of zero, in the NHRP Request packet. 1123 If an NHS is generating an NHRP Reply packet in response to a request 1124 containing this extension, it SHALL include this extension, 1125 containing its IP address, in the NHRP Reply. If an NHS has more 1126 than one IP address, it SHALL use the same IP address consistently in 1127 all of the Responder Address, Forward NHS Record, and Reverse NHS 1128 Record extensions. The choice of which of several IP addresses to 1129 include in this extension is a local matter. 1131 If an NHRP Reply packet being forwarded by an NHS contains an IP 1132 address of that NHS in the Responder Address Extension, the NHS SHALL 1133 generate an Error Indication of type "NHRP Loop Detected" and discard 1134 the Reply. 1136 If an NHRP Reply packet is being returned by an intermediate NHS 1137 based on cached data, it SHALL place its own address in this 1138 extension (differentiating it from the address in the Next-hop 1139 field). 1141 5.7.4 NHRP Forward NHS Record Extension (IPv4-Specific) 1143 Discretionary = 0 1144 Type = 4 1145 Length = variable 1147 The NHRP forward NHS record is a list of NHSs through which an NHRP 1148 request traverses. Each NHS SHALL append a Next-hop element 1149 containing its IP address to this extension. 1151 In addition, NHSs that are willing to act as egress routers for 1152 packets from the source to the destination SHALL include information 1153 about their NBMA Address. 1155 Each Next-hop element is formatted as follows: 1157 0 1 2 3 1158 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 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | IP address | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | Holding Time | Address Type | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | Unused | NBMA Length | NBMA Address (variable length)| 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 IP address 1168 The IP address of the NHS. 1170 Holding Time 1171 The number of seconds for which this information is valid. If a 1172 station chooses to use this information as a next-hop entry, it may 1173 not be used once the holding timer expires. 1175 Address Type, NBMA Length, and NBMA Address 1176 The Address Type field specifies the type of NBMA address 1177 (qualifying the NBMA address). Possible address types are listed 1178 in [6]. 1180 The NBMA length field is the length of the NBMA address of the 1181 destination station in bits. The NBMA address itself is zero- 1182 filled to the nearest 32-bit boundary. 1184 NHSs that are not egress routers SHALL specify an NBMA Length of 1185 zero and SHALL NOT include an NBMA Address. 1187 If a requestor wishes to obtain this information, it SHALL include 1188 this extension with a length of zero. 1190 Each NHS SHALL append an appropriate Next-hop element to this 1191 extension when processing an NHRP Request. The extension length 1192 field and NHRP checksum SHALL be adjusted as necessary. 1194 The last-hop NHS (the one that will be generating the NHRP Reply) 1195 SHALL NOT update this extension (since this information will be in 1196 the reply). 1198 If an NHS has more than one IP address, it SHALL use the same IP 1199 address consistently in all of the Responder Address, Forward NHS 1200 Record, and Reverse NHS Record extensions. The choice of which of 1201 several IP addresses to include in this extension is a local matter. 1203 If an NHRP Request packet being forwarded by an NHS contains the IP 1204 address of that NHS in the Forward NHS Record Extension, the NHS 1205 SHALL generate an Error Indication of type "NHRP Loop Detected" and 1206 discard the Request. 1208 5.7.5 NHRP Reverse NHS Record Extension (IPv4-Specific) 1210 Discretionary = 0 1211 Type = 5 1212 Length = variable 1213 The NHRP reverse NHS record is a list of NHSs through which an NHRP 1214 reply traverses. Each NHS SHALL append a Next-hop element containing 1215 its IP address to this extension. 1217 In addition, NHSs that are willing to act as egress routers for 1218 packets from the source to the destination SHALL include information 1219 about their NBMA Address. 1221 Each Next-hop element is formatted as follows: 1223 0 1 2 3 1224 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 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | IP address | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Holding Time | Address Type | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Unused | NBMA Length | NBMA Address (variable length)| 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 IP address 1234 The IP address of the NHS. 1236 Holding Time 1237 The number of seconds for which this information is valid. If a 1238 station chooses to use this information as a next-hop entry, it may 1239 not be used once the holding timer expires. 1241 Address Type, NBMA Length, and NBMA Address 1242 The Address Type field specifies the type of NBMA address 1243 (qualifying the NBMA address). Possible address types are listed 1244 in [6]. 1246 The NBMA length field is the length of the NBMA address of the 1247 destination station in bits. The NBMA address itself is zero- 1248 filled to the nearest 32-bit boundary. 1250 NHSs that are not egress routers SHALL specify an NBMA Length of 1251 zero and SHALL NOT include an NBMA Address. 1253 If a requestor wishes to obtain this information, it SHALL include 1254 this extension with a length of zero. 1256 Each NHS SHALL append an appropriate Next-hop element to this 1257 extension when processing an NHRP Reply. The extension length field 1258 and NHRP checksum SHALL be adjusted as necessary. 1260 The NHS generating the NHRP Reply SHALL NOT update this extension. 1262 If an NHS has more than one IP address, it SHALL use the same IP 1263 address consistently in all of the Responder Address, Forward NHS 1264 Record, and Reverse NHS Record extensions. The choice of which of 1265 several IP addresses to include in this extension is a local matter. 1267 If an NHRP Reply packet being forwarded by an NHS contains the IP 1268 address of that NHS in the Reverse NHS Record Extension, the NHS 1269 SHALL generate an Error Indication of type "NHRP Loop Detected" and 1270 discard the Reply. 1272 Note that this information may be cached at intermediate NHSs; if 1273 so, the cached value SHALL be used when generating a reply. Note 1274 that the Responder Address extension may be used to disambiguate the 1275 set of NHSs that actually processed the reply. 1277 5.7.6 NHRP QoS Extension 1279 Discretionary = 1 1280 Type = 6 1281 Length = variable 1283 The NHRP QoS Extension is carried in NHRP Request packets to indicate 1284 the desired QoS of the path to the indicated destination. This 1285 information may be used to help select the appropriate NBMA next hop. 1287 It may also be carried in NHRP Register packets to indicate the QoS 1288 to which the registration applies. 1290 The syntax and semantics of this extension are TBD; alignment with 1291 resource reservation may be useful. 1293 5.7.7 NHRP Authentication Extension 1295 Discretionary = 0 1296 Type = 7 1297 Length = variable 1299 The NHRP Authentication Extension is carried in NHRP packets to 1300 convey authentication information between NHRP speakers. The 1301 Authentication Extension may be included in any NHRP packet type. 1303 Authentication is done pairwise on an NHRP hop-by-hop basis; the 1304 authentication extension is regenerated on each hop. If a received 1305 packet fails the authentication test, the NHS SHALL generate an Error 1306 Indication of type "Authentication Failure" and discard the packet. 1307 In no case SHALL an Error Indication packet be generated on the 1308 receipt of an Error Indication packet, however. Note that one 1309 possible authentication failure is the lack of an Authentication 1310 Extension; the presence or absence of the Authentication Extension 1311 is a local matter. 1313 0 1 2 3 1314 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 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Authentication Type | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | | 1319 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1320 | | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 The Authentication Type field identifies the authentication method in 1324 use. Currently assigned values are: 1326 1 - Cleartext Password 1327 2 - Keyed MD5 1329 All other values are reserved. 1331 The Authentication Data field contains the type-specific 1332 authentication information. 1334 In the case of Cleartext Password Authentication, the Authentication 1335 Data consists of a variable length password. 1337 In the case of Keyed MD5 Authentication, the Authentication Data 1338 contains the 16 byte MD5 digest of the entire NHRP packet, including 1339 the IP header, with the authentication key appended to the end of the 1340 packet. The authentication key is not transmitted with the packet. 1342 Distribution of authentication keys is outside the scope of this 1343 document. 1345 5.7.8 NHRP Vendor-Private Extension 1347 Discretionary = 1 1348 Type = 8 1349 Length = variable 1351 The NHRP Vendor-Private Extension is carried in NHRP packets to 1352 convey vendor-private information or NHRP extensions between NHRP 1353 speakers. This extension may be used at any time; if the receiver 1354 does not handle this extension, or does not match the vendor ID in 1355 the extension, then the extension may be completely ignored by the 1356 receiver. The first 24 bits of the extension's payload (following 1357 the length field) contains the 802 vendor ID as assigned by the IEEE 1358 [6]. The remaining octets in the payload are vendor-dependent. 1360 6. Protocol Operation 1362 In this section, we discuss certain operational considerations of 1363 NHRP. 1365 6.1 Router-to-Router Operation 1367 In practice, the initiating and responding stations may be either 1368 hosts or routers. However, there is a possibility under certain 1369 conditions that a stable routing loop may occur if NHRP is used 1370 between two routers. In particular, attempting to establish an NHRP 1371 path across a boundary where information used in route selection is 1372 lost may result in a routing loop. Such situations include the loss 1373 of BGP path vector information, the interworking of multiple routing 1374 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 1375 circumstances, NHRP should not be used. This situation can be 1376 avoided if there are no "back door" paths between the entry and 1377 egress router outside of the NBMA subnetwork. Protocol mechanisms to 1378 relax these restrictions are under investigation. 1380 In general it is preferable to use mechanisms, if they exist, in 1381 routing protocols to resolve the egress point when the destination 1382 lies outside of the NBMA subnetwork, since such mechanisms will be 1383 more tightly coupled to the state of the routing system and will 1384 probably be less likely to create loops. 1386 6.2 Handling of IP Destination Address Field 1388 NHRP packets are self-contained in terms of the IP addressing 1389 information needed for protocol operation--the IP source and 1390 destination addresses in the encapsulating IP header are not used. 1391 However, the setting of the IP destination address field does impact 1392 how NHRP requests are forwarded. 1394 There are essentially three choices in how to set the destination IP 1395 address field at any particular point in the forwarding of an NHRP 1396 request: the ultimate destination being resolved, the next-hop IP 1397 router on the path to the destination, and the next-hop NHS (which 1398 might not be adjacent to the NHS forming the packet header). 1400 The first case, addressing the packet to the destination being 1401 resolved (in the hopes that an NHS lies along the path) is desirable 1402 for at least two reasons. It simplifies configuration (since the 1403 identity of the next NHS need not be known explicitly), and it 1404 simplifies deployment (since the packet will pass silently through 1405 routers that are not NHSs). However, it assumes that the serving NHS 1406 lies along the path to the destination, and it requires NHSs along 1407 the path to examine the packet even though it is not addressed to 1408 them. 1410 The second case, addressing the packet to the next-hop router, is 1411 similar to the first in that it follows the path to the destination, 1412 thus reducing configuration complexity. It furthermore only requires 1413 NHSs to process the packet if they are directly addressed. It too 1414 assumes that the responding NHS is on the path to the destination. 1415 However, it requires that all routers along the path are also NHSs. 1417 The third case, addressing the packet to the next-hop NHS, allows the 1418 NHSs to be independent of routing, and requires only addressed NHSs 1419 to examine the packet. However, there is no reasonable way, other 1420 than manual configuration, to determine the identity of the next hop 1421 NHS if it is not also the next hop IP router (making it option two). 1423 In order to balance all of these issues, the following rules SHALL be 1424 used when constructing IP packets to carry NHRP requests. 1426 Stations 1428 Stations SHALL address NHRP packets to the NHS by which they are 1429 served, regardless of whether NHRP has been deployed in Server mode 1430 or Fabric mode. 1432 NHSs 1434 If an NHS receives an NHRP packet in which the IP destination 1435 address does not match any of its own IP addresses, it SHALL 1436 process the NHRP packet as appropriate, and if it MUST forward the 1437 NHRP packet to another NHS, SHALL transmit the packet with the same 1438 IP destination address with which it was received. 1440 If an NHS receives an NHRP packet in which the IP destination 1441 address matches one of its own IP addresses, it SHALL process the 1442 NHRP packet as appropriate, and if it MUST forward the NHRP packet 1443 to another NHS, SHALL set the destination IP address in one of the 1444 following ways: 1446 If there is a configured next-hop NHS for the destination being 1447 resolved (Server mode), it SHALL transmit the packet with the IP 1448 destination address set to the next-hop NHS. 1450 If there is no configured next-hop NHS (Fabric Mode), it SHALL 1451 transmit the packet with the IP destination address set to the 1452 address of the destination being resolved, and SHALL include the 1453 Router Alert option [5] so that intermediate NHS/routers can 1454 examine the NHRP packet. 1456 6.3 Cache Management Issues 1458 The management of NHRP caches in the source station, the NHS serving 1459 the destination, and any intermediate NHSs is dependent on a number 1460 of factors. 1462 6.3.1 Cacheing Requirements 1464 Source Stations 1466 Source stations must of course cache all received replies that they 1467 are actively using. They also must cache "incomplete" entries, 1468 i.e., those for which a request has been sent but which a reply has 1469 not been received. This is necessary in order to preserve the 1470 Request ID for retries, and provides the state necessary to avoid 1471 triggering requests for every data packet sent to the destination. 1473 Source stations MUST purge expired information from their caches. 1474 Source stations MUST purge the appropriate cached information upon 1475 receipt of an NHRP Purge request packet. 1477 Source stations that are also NHSs may return cached information 1478 learned in response to its own NHRP Request packets in reply to 1479 requests it receives, within the rules for Transit NHSs below. 1481 Serving NHSs 1483 The NHS serving the destination (the one which responds 1484 authoritatively to NHRP requests) MUST cache information about all 1485 requests to which it has responded if the information in the reply 1486 has the possibility of changing during its lifetime (so that an 1487 NHRP Purge request packet can be sent). The NBMA information 1488 provided by the source station in the NHRP Request may be cached 1489 for the duration of its holding time. This information is 1490 considered to be stable, since it identifies a station directly 1491 attached to the NBMA subnetwork. 1493 Transit NHSs 1495 A Transit NHS (lying along the NHRP path between the source station 1496 and the responding NHS) may cache information contained in NHRP 1497 Request packets that it forwards. A Transit NHS may cache 1498 information contained in NHRP Reply packets that it forwards only 1499 if that reply has the Stable (B) bit set. It MUST discard any 1500 cached information whose holding time has expired. It may return 1501 cached information in response to non-authoritative requests only. 1503 6.3.2 Dynamics of Cached Information 1505 NBMA-Connected Destinations 1507 NHRP's most basic function is that of simple NBMA address 1508 resolution of stations directly attached to the NBMA subnetwork. 1509 These mappings are typically very static, and appropriately chosen 1510 holding times will minimize problems in the event that the NBMA 1511 address of a station must be changed. Stale information will cause 1512 a loss of connectivity, which may be used to trigger an 1513 authoritative NHRP request and bypass the old data. In the worst 1514 case, connectivity will fail until the cache entry times out. 1516 This applies equally to information marked in replies as being 1517 "stable" (via the "B" bit). 1519 This also applies equally well to source stations that are routers 1520 as well as those which are hosts. 1522 Note that the information carried in the NHRP Request packet is 1523 always considered "stable" because it represents a station that is 1524 directly connected to the NBMA subnetwork. 1526 Destinations Off of the NBMA Subnetwork 1528 If the source of a request is a host and the destination is not 1529 directly attached to the NBMA subnetwork and is not considered to 1530 be "stable," the destination mapping may be very dynamic (except in 1531 the case of a subnetwork where each destination is only singly 1532 homed to the NBMA subnetwork). As such the cached information may 1533 very likely become stale. The consequence of stale information in 1534 this case will be a suboptimal path (unless the internetwork has 1535 partitioned or some other routing failure has occurred). 1537 If the egress router/NHS detects a routing change toward the 1538 destination, it MUST send an NHRP Purge packet to the source, which 1539 will usually cause the source to issue a authoritative request and 1540 find the new egress point. If the egress router for some reason 1541 sees no change in routing toward the destination, then it should 1542 still be a viable, if suboptimal, hop toward the destination. The 1543 consequence of the source making a non-authoritative request after 1544 a Purge, in the presence of stale cache entries (not removed by a 1545 Purge), is also suboptimal routing. 1547 6.4 Use of the Destination Prefix Extension 1549 A certain amount of care needs to be taken when using the Destination 1550 Prefix Extension, in particular with regard to the prefix length 1551 advertised (and thus the size of the equivalence class specified by 1552 it). Assuming that the routers on the NBMA subnetwork are exchanging 1553 routing information, it should not be possible for an NHS to create a 1554 black hole by advertising too large of a set of destinations, but 1555 suboptimal routing can result. For example, it should not be assumed 1556 that the proper prefix to advertise is the one provided by the 1557 routing system (especially if the prefix is determined from the 1558 default route). 1560 The approach used to determine the prefix width is likely to vary 1561 based on the particulars of the situation. Information could be 1562 gleaned from local topology, routing protocols, and other sources. 1564 In general, the width of the prefix should be handled conservatively 1565 (erring toward a longer prefix). 1567 If multiple cache entries match the desired destination address (due 1568 to overlapping prefixes), the longest prefix MUST be used. 1570 7. Security Considerations 1572 As in any routing protocol, there are a number of potential security 1573 attacks possible, particularly denial-of-service attacks. The use of 1574 authentication on all packets is recommended to avoid such attacks. 1576 The authentication schemes described in this document are intended to 1577 allow the receiver of a packet to validate the identity of the 1578 sender; they do not provide privacy or protection against replay 1579 attacks. 1581 Detailed security analysis of this protocol is for further study. 1583 8. Discussion 1585 The result of an NHRP request depends on how routing is configured 1586 among the NHSs of an NBMA subnetwork. If the destination station is 1587 directly connected to the NBMA subnetwork and the the routed path to 1588 it lies entirely within the NBMA subnetwork, the NHRP replies always 1589 return the NBMA address of the destination station itself rather than 1590 the NBMA address of some egress router. On the other hand, if the 1591 routed path exits the NBMA subnetwork, NHRP will be unable to resolve 1592 the NBMA address of the destination, but rather will return the 1593 address of the egress router. For destinations outside the NBMA 1594 subnetwork, egress routers and routers in the other subnetworks 1595 should exchange routing information so that the optimal egress router 1596 may be found. 1598 When the NBMA next hop toward a destination is not the destination 1599 station itself, the optimal NBMA next hop may change dynamically. 1600 This can happen, for instance, when an egress router nearer to the 1601 destination becomes available. This change can be detected in a 1602 number of ways. First of all, the source station will need to 1603 periodically reissue the NHRP Request at a minimum just prior to the 1604 expiration of the holding timer. Alternatively, the source can be 1605 configured to receive routing information from the routing system. 1606 When it detects an improvement in the route to the destination, the 1607 source can reissue the NHRP request to obtain the current optimal 1608 NBMA next hop. Source stations that are routers may choose to 1609 establish a routing association with the egress router, allowing the 1610 egress router to explicitly inform the source about changes in 1611 routing (and providing additional routing information, 1612 authentication, etc.) Such strategies will be discussed in a 1613 separate document. 1615 In addition to NHSs, an NBMA station could also be associated with 1616 one or more regular routers that could act as "connectionless 1617 servers" for the station. The station could then choose to resolve 1618 the NBMA next hop or just send the IP packets to one of its 1619 connectionless servers. The latter option may be desirable if 1620 communication with the destination is short-lived and/or doesn't 1621 require much network resources. The connectionless servers could, of 1622 course, be physically integrated in the NHSs by augmenting them with 1623 IP switching functionality. 1625 References 1627 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 1628 Govindan, draft-ietf-rolc-nbma-arp-00.txt. 1630 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 1632 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 1634 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 1635 and D. Piscitello, RFC 1209. 1637 [5] IP Router Alert Option, Dave Katz, draft-katz-router-alert- 1638 00.txt. 1640 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 1642 [7] Protocol Identification in the Network Layer, ISO/IEC TR 1643 9577:1990. 1645 Acknowledgements 1647 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 1648 Govidan of ISI for their work on NBMA ARP and the original NHRP 1649 draft, which served as the basis for this work. John Burnett of 1650 Adaptive, Dennis Ferguson of ANS, Joel Halpern of Newbridge, Paul 1651 Francis of NTT, and Tony Li and Bruce Cole of cisco should also be 1652 acknowledged for comments and suggestions that improved this work 1653 substantially. We would also like to thank the members of the 1654 Routing Over Large Clouds working group of the IETF, whose review and 1655 discussion of this document have been invaluable. 1657 Authors' Addresses 1659 Dave Katz David Piscitello 1660 cisco Systems Core Competence 1661 170 W. Tasman Dr. 1620 Tuckerstown Road 1662 San Jose, CA 95134 USA Dresher, PA 19025 USA 1664 Phone: +1 408 526 8284 Phone: +1 215 830 0692 1665 Email: dkatz@cisco.com Email: dave@corecom.com