idnits 2.17.1 draft-ietf-rolc-nhrp-06.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-18) 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 197 instances of too long lines in the document, the longest one being 10 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 224: '...n Request for a given destination MUST...' RFC 2119 keyword, line 255: '...n Request. NHSs MUST NOT respond to a...' RFC 2119 keyword, line 286: '...ests and replies MUST NOT cross the bo...' RFC 2119 keyword, line 464: '...e Mandatory Part MUST be present, but ...' RFC 2119 keyword, line 496: '... marked "unused" MUST be set to zero o...' (80 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 654 has weird spacing: '.... This value...' == Line 1481 has weird spacing: '...rotocol addre...' -- 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 (November 1995) is 10382 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 484 -- Looks like a reference, but probably isn't: '0x00-00-5E' on line 484 -- Looks like a reference, but probably isn't: '0x00-03' on line 484 == Unused Reference: '5' is defined on line 2131, but no explicit reference was found in the text ** 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) -- 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) Summary: 17 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing over Large Clouds Working Group Dave Katz 2 INTERNET-DRAFT (cisco Systems) 3 David Piscitello 4 (Core Competence, Inc.) 5 Bruce Cole 6 (cisco Systems) 7 James V. Luciani 8 (Ascom Nexion) 9 November 1995 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 IP and 36 NBMA subnetwork addresses of the "NBMA next hop" towards a 37 destination station. If the destination is connected to the NBMA 38 subnetwork, then the NBMA next hop is the destination station itself. 39 Otherwise, the NBMA next hop is the egress router from the NBMA 40 subnetwork that is "nearest" to the destination station. Although 41 this document focuses on NHRP in the context of IP, the technique is 42 applicable to other internetwork layer protocols (e.g., IPX, CLNP, 43 Appletalk) as well. 45 This document is intended to be a functional superset of the NBMA 46 Address Resolution Protocol (NARP) documented in [1]. 48 Operation of NHRP as a means of establishing a transit path across an 49 NBMA subnetwork between two routers will be addressed in a separate 50 document. 52 1. Introduction 54 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 55 (a host or router), wishing to communicate over a Non-Broadcast, 56 Multi-Access (NBMA) subnetwork, to determine the IP and NBMA 57 addresses of the "NBMA next hop" toward a destination station. A 58 subnetwork can be non-broadcast either because it technically doesn't 59 support broadcasting (e.g., an X.25 subnetwork) or because 60 broadcasting is not feasible for one reason or another (e.g., an SMDS 61 multicast group or an extended Ethernet would be too large). If the 62 destination is connected to the NBMA subnetwork, then the NBMA next 63 hop is the destination station itself. Otherwise, the NBMA next hop 64 is the egress router from the NBMA subnetwork that is "nearest" to 65 the destination station. 67 An NBMA subnetwork may, in general, consist of multiple logically 68 independent IP subnets (LISs), defined in [3] and [4] as having the 69 following properties: 71 1) All members of a LIS have the same IP network/subnet number 72 and address mask. 74 2) All members within a LIS are directly connected to the same 75 NBMA subnetwork. 77 3) All members outside of the LIS are accessed via a router. 79 IP routing described in [3] and [4] only resolves the next hop 80 address if the destination station is a member of the same LIS as the 81 source station; otherwise, the source station must forward packets to 82 a router that is a member of multiple LIS's. In multi-LIS 83 configurations, hop-by-hop IP routing may not be sufficient to 84 resolve the "NBMA next hop" toward the destination station, and IP 85 packets may traverse the NBMA subnetwork more than once. 87 NHRP describes a routing method that relaxes the forwarding 88 restrictions of the LIS model. With NHRP, once the NBMA next hop has 89 been resolved, the source may either start sending IP packets to the 90 destination (in a connectionless NBMA subnetwork such as SMDS) or may 91 first establish a connection to the destination with the desired 92 bandwidth and QOS characteristics (in a connection-oriented NBMA 93 subnetwork such as ATM). 95 NHRP in its most basic form provides a simple IP-to-NBMA-address 96 binding service. This may be sufficient for hosts which are directly 97 connected to an NBMA subnetwork, allowing for straightforward 98 implementations in NBMA stations. NHRP also has the capability of 99 determining the egress point from an NBMA subnetwork when the 100 destination is not directly connected to the NBMA subnetwork and the 101 identity of the egress router is not learned by other methods (such 102 as routing protocols). Optional extensions to NHRP provide 103 additional robustness and diagnosability. 105 Address resolution techniques such as those described in [3] and [4] 106 may be in use when NHRP is deployed. ARP servers and services over 107 NBMA subnetworks may be required to support hosts that are not 108 capable of dealing with any model for communication other than the 109 LIS model, and deployed hosts may not implement NHRP but may continue 110 to support ARP variants such as those described in [3] and [4]. NHRP 111 is intended to reduce or eliminate the extra router hops required by 112 the LIS model, and can be deployed in a non-interfering manner 113 alongside existing ARP services. 115 The operation of NHRP to establish transit paths across NBMA 116 subnetworks between two routers requires additional mechanisms to 117 avoid stable routing loops, and will be described in a separate 118 document. 120 2. Overview 122 2.1 Terminology 124 The term "network" is highly overloaded, and is especially confusing 125 in the context of NHRP. We use the following terms: 127 Internetwork layer--the media-independent layer (IP in the case of 128 TCP/IP networks). 130 Subnetwork layer--the media-dependent layer underlying the 131 internetwork layer, including the NBMA technology (ATM, X.25, SMDS, 132 etc.) 134 2.2 Protocol Overview 136 In this section, we briefly describe how a source S (which 137 potentially can be either a router or a host) uses NHRP to determine 138 the "NBMA next hop" to destination D. 140 For administrative and policy reasons, a physical NBMA subnetwork may 141 be partitioned into several, disjoint "Logical NBMA subnetworks". A 142 Logical NBMA subnetwork is defined as a collection of hosts and 143 routers that share unfiltered subnetwork connectivity over an NBMA 144 subnetwork. "Unfiltered subnetwork connectivity" refers to the 145 absence of closed user groups, address screening or similar features 146 that may be used to prevent direct communication between stations 147 connected to the same NBMA subnetwork. (Hereafter, unless otherwise 148 specified, we use the term "NBMA subnetwork" to mean *logical* NBMA 149 subnetwork.) 151 Placed within the NBMA subnetwork are one or more entities that 152 implement the NHRP protocol. Such stations which are capable of 153 answering Next Hop Resolution Requests are known as "Next Hop 154 Servers" (NHSs). Each NHS serves a set of destination hosts, which 155 may or may not be directly connected to the NBMA subnetwork. NHSs 156 cooperatively resolve the NBMA next hop within their logical NBMA 157 subnetwork. In addition to NHRP, NHSs may participate in protocols 158 used to disseminate routing information across (and beyond the 159 boundaries of) the NBMA subnetwork, and may support "classical" ARP 160 service as well. 162 An NHS maintains a "next-hop resolution" cache, which is a table of 163 address mappings (IP-to-NBMA address). This table can be constructed 164 from information gleaned from NHRP Register packets (see Section 165 5.2.3 and 5.2.4), extracted from Next Hop Resolution Requests or 166 replies that traverse the NHS as they are forwarded, or through 167 mechanisms outside the scope of this document (examples of such 168 mechanisms include ARP [2, 3, 4] and pre-configured tables). Section 169 6.2 further describes cache management issues. 171 A host or router that is not an NHRP server must be configured with 172 the identity of the NHS which serves it (see Configuration, Section 173 4). 175 [Note: for NBMA subnetworks that offer group or multicast addressing 176 features, it may be desirable to configure stations with a group 177 identity for NHSs, i.e., addressing information that would solicit a 178 response from "all NHSs". The means whereby a group of NHSs divide 179 responsibilities for next hop resolution are not described here.] 181 Whether or not a particular station within the NBMA subnetwork which 182 is making use of the NHRP protocol needs to be able to act as an NHS 183 is a local matter. For a station to avoid providing NHS 184 functionality, there must be one or more NHSs within the NBMA 185 subnetwork which are providing authoritative NBMA information on its 186 behalf. If NHRP is to be able to resolve the NBMA address for 187 stations that lack NHS functionality, these serving NHSs must exist 188 along all routed paths between Next Hop Resolution Requesters and the 189 station which cannot answer Next Hop Resolution Requests. 191 The protocol proceeds as follows. An event occurs triggering station 192 S to want to resolve the NBMA address of a path to D. This is most 193 likely to be when a data packet addressed to station D is to be 194 emitted from station S (either because station S is a host, or 195 station S is a transit router), but the address resolution could also 196 be triggered by other means (a routing protocol update packet, for 197 example). Station S first determines the next hop to station D 198 through normal routing processes (for a host, the next hop may simply 199 be the default router; for routers, this is the "next hop" to the 200 destination IP address). If the next hop is reachable through its 201 NBMA interface, S constructs an Next Hop Resolution Request packet 202 (see Section 5.2.1) containing station D's IP address as the (target) 203 destination address, S's own IP address as the source address (Next 204 Hop Resolution Request initiator), and station S's NBMA addressing 205 information. Station S may also indicate that it prefers an 206 authoritative reply (i.e., station S only wishes to receive a reply 207 from the NHS-speaker that maintains the NBMA-to-IP address mapping 208 for this destination). Station S emits the Next Hop Resolution 209 Request packet towards the destination, using the NBMA address of the 210 next routed hop. 212 If the Next Hop Resolution Request is triggered by a data packet, 213 station S may choose to dispose of the data packet while awaiting an 214 NHRP reply in one of the following ways: 216 (a) Drop the packet 217 (b) Retain the packet until the reply arrives and a more optimal 218 path is available 219 (c) Forward the packet along the routed path toward D 221 The choice of which of the above to perform is a local policy matter, 222 though option (c) is the recommended default, since it may allow data 223 to flow to the destination while the NBMA address is being resolved. 224 Note that an Next Hop Resolution Request for a given destination MUST 225 NOT be triggered on every packet, though periodically retrying a Next 226 Hop Resolution Request is permitted. 228 When the NHS receives an Next Hop Resolution Request, a check is made 229 to see if it "serves" station D, i.e., the NHS checks to see if there 230 is a "next hop" entry for D in its next-hop resolution cache. If the 231 NHS does not serve D, the NHS forwards the Next Hop Resolution 232 Request to another NHS. (Mechanisms for determining how to forward 233 the Next Hop Resolution Request are discussed in Section 3, 234 Deployment.) Note that because NHRP packets are encapsulated with the 235 NBMA address of neighboring stations (see encapsulation discussion, 236 section 5), NHSs must be next hops to one another in order for 237 forwarding of these packets to be possible. 239 If this NHS serves D, the NHS resolves station D's NBMA address, and 240 generates a positive NHRP reply on D's behalf. (NHRP replies in this 241 scenario are always marked as "authoritative".) The NHRP reply 242 packet contains the next hop IP and NBMA address for station D and is 243 sent back to S. (Note that if station D is not on the NBMA 244 subnetwork, the next hop IP address will be that of the egress router 245 through which packets for station D are forwarded.) 247 An NHS receiving an NHRP reply may cache the NBMA next hop 248 information contained therein. To a subsequent Next Hop Resolution 249 Request, this NHS may respond with the cached, non-authoritative, 250 NBMA next hop information or with cached negative information, if the 251 NHS is allowed to do so, see section 6.2. Non-authoritative NHRP 252 replies are distinguished from authoritative replies so that if a 253 communication attempt based on non-authoritative information fails, a 254 source station can choose to send an authoritative Next Hop 255 Resolution Request. NHSs MUST NOT respond to authoritative Next Hop 256 Resolution Requests with cached information. 258 [Note: An NHRP reply can be returned directly to the Next Hop 259 Resolution Request initiator, i.e., without traversing the list of 260 NHSs that forwarded the request, if all of the following criteria 261 are satisfied: 263 (a) Direct communication is available via datagram transfer 264 (e.g., SMDS) or the NHS has an existing virtual circuit 265 connection to the Next Hop Resolution Request initiator or is permitted 266 to open one. 267 (b) The Next Hop Resolution Request initiator has not included the NHRP 268 Reverse NHS record Extension (see Section 5.3.5). 269 (c) The authentication policy in force permits direct 270 communication between the NHS and the Next Hop Resolution Request 271 initiator. 273 The purpose of allowing an NHS to reply directly is to reduce 274 response time. A consequence of allowing a direct reply is that 275 NHSs that would under normal circumstances be traversed by the 276 reply would not cache next hop information contained therein.] 278 The process of forwarding the Next Hop Resolution Request is repeated 279 until the request is satisfied, or an error occurs (e.g., no NHS in 280 the NBMA subnetwork can resolve the request.) If the determination is 281 made that station D's next hop cannot be resolved, a negative reply 282 is returned. This occurs when (a) no next-hop resolution information 283 is available for station D from any NHS, or (b) an NHS is unable to 284 forward the Next Hop Resolution Request (e.g., connectivity is lost). 286 Next Hop Resolution Requests and replies MUST NOT cross the borders 287 of a logical NBMA subnetwork (an explicit NBMA subnetwork identifier 288 may be included as an extension in the Next Hop Resolution Request, 289 see section 5.3.2). Thus, IP traffic out of and into a logical NBMA 290 subnetwork always traverses an IP router at its border. Internetwork 291 layer filtering can then be implemented at these border routers. 293 NHRP optionally provides a mechanism to reply with aggregated NBMA 294 next hop information. Suppose that router X is the NBMA next hop 295 from station S to station D. Suppose further that X is an egress 296 router for all stations sharing an IP address prefix with station D. 297 When an NHRP reply is generated in response to a request, the 298 responder may augment the IP address of station D with a mask 299 defining this prefix (see Section 5.3.1). A subsequent (non- 300 authoritative) Next Hop Resolution Request for some destination that 301 shares an IP address prefix with D may be satisfied with this cached 302 information. See section 6.2 regarding caching issues. 304 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 305 (e.g., X.25 closed user group facility, or SMDS address screens), as 306 well as to provide loop detection and diagnostic capabilities, NHRP 307 optionally incorporates a "Route Record" in requests and replies (see 308 Sections 5.3.4 and 5.3.5). The Route Record extensions contain the 309 internetwork (and subnetwork layer) addresses of all intermediate 310 NHSs between source and destination (in the forward direction) and 311 between destination and source (in the reverse direction). When a 312 source station is unable to communicate with the responder (e.g., an 313 attempt to open an SVC fails), it may attempt to do so successively 314 with other subnetwork layer addresses in the Route Record until it 315 succeeds (if authentication policy permits such action). This 316 approach can find a suitable egress point in the presence of 317 subnetwork-layer filtering (which may be source/destination 318 sensitive, for instance, without necessarily creating separate 319 logical NBMA subnetworks) or subnetwork-layer congestion (especially 320 in connection-oriented media). 322 NHRP messages, with the exception of Purge packets, are sent using a 323 best effort delivery service. Next Hop Resolution Requests should be 324 retransmitted periodically until either a Reply or an Error packet is 325 received. 327 3. Deployment 329 Next Hop Resolution Requests traverse one or more hops within an NBMA 330 subnetwork before reaching the station that is expected to generate a 331 response. Each station, including the source station, chooses a 332 neighboring NHS to forward the request on to. The NHS selection 333 procedure typically involves performing a routing decision based upon 334 the network layer destination address of the Next Hop Resolution 335 Request. Ignoring error situations, the Next Hop Resolution Request 336 eventually arrives at a station that is to generate an NHRP reply. 337 This responding station either serves the destination, or is the 338 destination itself if both NHRP client and server functionality are 339 co-resident in the same station. The responding station generates a 340 reply using the source address from within the NHRP packet to 341 determine where the reply should be sent. 343 The Next Hop Resolution Request packet is carried at the NBMA layer, 344 with a destination NBMA address set to that of the locally determined 345 NHS. If the addressed NHS does not serve the destination address 346 specified in the Next Hop Resolution Request, the request packet is 347 routed at the network layer based upon the request's destination 348 address, and forwarded to the neighboring NHS determined by the 349 routing decision. Alternately, the NHS may use static configuration 350 information in order to determine which neighboring NHSs to forward 351 the request packet to. Each NHS/router examines the NHRP request 352 packet on its way toward the destination, optionally modifying it on 353 the way (such as updating the Forward Record extension), and 354 continues to forward it until it reaches the NHS that serves the 355 destination network layer address. 357 In order to forward NHRP packets to a neighboring NHS, NHRP clients 358 must nominally be configured with the NBMA address of at least one 359 NHS. In practice, a client's default router should also be its NHS. 360 A client may be able to derive the NBMA address of its NHS from the 361 configuration that was already required for the client to be able to 362 communicate with its next hop router. 364 Forwarding of NHRP packets within an NBMA subnetwork requires a 365 contiguous deployment of NHRP capable stations. During migration to 366 NHRP, it cannot be expected that all stations within the NBMA 367 subnetwork are NHRP capable. NHRP traffic which would otherwise need 368 to be forwarded through such stations can be expected to be dropped 369 due to the NHRP packet being unrecognized. In this case, NHRP will 370 be unable to establish any transit paths whose discovery requires the 371 traversal of the non-NHRP speaking stations. In such a scenario, 372 NHRP is still able to provide basic address resolution functionality 373 between stations which do support NHRP. 375 The path taken by Next Hop Resolution Requests will normally be the 376 same as the path taken by data packets which are routed at the 377 network layer to the desired destination. (The paths may be 378 different in situations where NHSs have been statically configured to 379 forward traffic by other means. For example, an Next Hop Resolution 380 Request may be forwarded to a group multicast address.) 382 NHSs should acquire knowledge about destinations other NHSs serve as 383 a direct consequence of participating in intradomain and interdomain 384 routing protocol exchange. In this case, the NHS serving a 385 particular destination must lie along the routed path to that 386 destination. In practice, this means that all egress routers must 387 double as NHSs serving the destinations beyond them, and that hosts 388 on the NBMA subnetwork are served by routers that double as NHSs. 390 NHSs (and end stations) may alternately be statically configured with 391 the NBMA addresses of their neighbors, the identities of the 392 destinations that each of them serves, and optionally a logical NBMA 393 subnetwork identifier. Such static configurations may be necessary 394 in cases where NHSs do not contain network layer routing protocol 395 implementations. 397 If the NBMA subnetwork offers a group addressing or multicast 398 feature, the client (station) may be configured with a group address 399 assigned to the group of next-hop servers. The client might then 400 submit Next Hop Resolution Requests to the group address, eliciting a 401 response from one or more NHSs, depending on the response strategy 402 selected. Note that the constraints described in Section 2 regarding 403 direct replies may apply. 405 NHSs may also be deployed with the group or multicast address of 406 their peers, and an NHS might use this as a means of forwarding Next 407 Hop Resolution Requests it cannot satisfy to its peers. This might 408 elicit a response (to the NHS) from one or more NHSs, depending on 409 the response strategy. The NHS would then forward the NHRP reply to 410 the Next Hop Resolution Request originator. The purpose of using 411 group addressing or a similar multicast mechanism in this scenario 412 would be to eliminate the need to preconfigure each NHS in a logical 413 NBMA subnetwork with both the individual identities of other NHSs as 414 well as the destinations they serve. It reduces the number of NHSs 415 that might be traversed to process an Next Hop Resolution Request (in 416 those configurations where NHSs either respond or forward via the 417 multicast, only two NHSs would be traversed), and allows the NHS that 418 serves the Next Hop Resolution Request originator to cache next hop 419 information associated with the reply (again, within the constraints 420 described in Section 2). 422 4. Configuration 424 Stations 426 To participate in NHRP, a station connected to an NBMA subnetwork 427 should be configured with the NBMA address(es) of its NHS(s) 428 (alternatively, it should be configured with a means of acquiring 429 them, i.e., the group address that members of a NHS group use for 430 the purpose of address or next-hop resolution.) The NHS(s) will 431 likely also represent the stations's default or peer routers, so 432 their NBMA addresses may be obtained from the station's existing 433 configuration. If the station is attached to several subnetworks 434 (including logical NBMA subnetworks), the station should also be 435 configured to receive routing information from its NHS(s) and peer 436 routers so that it can determine which IP networks are reachable 437 through which subnetworks. 439 Next Hop Servers 441 An NHS is configured with knowledge of its own IP and NBMA 442 addresses, a set of IP address prefixes that correspond to the IP 443 addresses of the stations it serves, and a logical NBMA subnetwork 444 identifier (see Section 5.3.2). If a served station is attached to 445 several subnetworks, the NHS may also need to be configured to 446 advertise routing information to such stations. 448 If an NHS acts as an egress router for stations connected to other 449 subnetworks than the NBMA subnetwork, the NHS must, in addition to 450 the above, be configured to exchange routing information between 451 the NBMA subnetwork and these other subnetworks. 453 In all cases, routing information is exchanged using conventional 454 intra-domain and/or inter-domain routing protocols. 456 The NBMA addresses of the stations served by the NHS may be learned 457 via NHRP Register packets or manual configuration. 459 5. NHRP Packet Formats 460 This section describes the format of NHRP packets. 462 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 463 Extensions Part. The Fixed Part is common to all NHRP packet types. 464 The Mandatory Part MUST be present, but varies depending on packet 465 type. The Extensions Part also varies depending on packet type, and 466 need not be present. 468 The length of the Fixed Part is fixed at 20 octets. The length of 469 the Mandatory Part is determined by the contents of the extensions 470 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 471 length is equal to total packet length (ar$pktsz) minus 20 otherwise 472 the mandatory part lenth is equal to ar$extoff minus 20. The length 473 of the Extensions Part is implied by ar$pktsz minus ar$extoff minus 474 20. NHSs may increase the size of an NHRP packet as a result of 475 extension processing, but not beyond the offered maximum SDU size of 476 the NBMA network. 478 NHRP packets are encapsulated using the native formats used on the 479 particular NBMA network over which NHRP is carried. For example, 480 SMDS networks always use LLC/SNAP encapsulation at the NBMA layer, 481 and an NHRP packet is preceded by the following LLC/SNAP 482 encapsulation: 484 [0xAA-AA-03] [0x00-00-5E] [0x00-03] 486 The first three octets are LLC, indicating that SNAP follows. The 487 SNAP OUI portion is the IANA's OUI, and the SNAP PID portion 488 identifies NHRP (see [4]). 490 ATM uses either LLC/SNAP encapsulation of each packet (including 491 NHRP), or uses no encapsulation on VCs dedicated to a single protocol 492 (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or 493 identification of NHRP, using a NLPID of 0x0080 and the same SNAP 494 contents as above (see [8], [9]). 496 Fields marked "unused" MUST be set to zero on transmission, and 497 ignored on receipt. 499 Most packet types (ar$op.type) have both internetwork layer 500 protocol-independent fields and protocol-specific fields. The 501 protocol-independent fields always come first in the packet, and the 502 protocol type/snap fields (ar$pro.type/snap) qualify the format of 503 the protocol-specific fields. 505 5.1 NHRP Fixed Header 507 The Fixed Part of the NHRP packet contains those elements of the NHRP 508 packet which are always present and do not vary in size with the type 509 of packet. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | ar$hrd | ar$pro.type | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | ar$pro.snap | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | ar$pro.snap | ar$hopcnt | ar$pktsz | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | ar$chksum | ar$extoff | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | ar$op.version | ar$op.type | ar$shtl | ar$sstl | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 ar$hrd 526 Defines the type of "link layer" addresses being carried. This 527 number is taken from the number hardware type from the list in [6]. 529 ***The use of the number hardware type or of the address family number 530 is still an open issue. 532 ar$pro.type 533 field is a 16 bit unsigned integer representing the following 534 number space: 536 0x0000 to 0x00FF Protocols defined by the equivalent NPLIDs. 537 0x0100 to 0x03FF Reserved for future use by the IETF. 538 0x0400 to 0x04FF Allocated for use by the ATM Forum. 539 0x0500 to 0x05FF Experimental/Local use. 540 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 542 (based on the observations that valid Ethertypes are never smaller 543 than 0x600, and NPLIDs never larger than 0xFF.) 545 ar$pro.snap 546 When ar$pro.type has a value of 0x0080, a SNAP encoded extension is 547 being used to encode the protocol type. This snap extension is 548 placed in the ar$pro.snap field. This is termed the 'long form' 549 protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be 550 zero on transmit and ignored on receive. The ar$pro.type field 551 itself identifies the protocol being referred to. This is termed 552 the 'short form' protocol ID. 554 In all cases, where a protocol has an assigned number in the 555 ar$pro.type space (excluding 0x0080) the short form MUST be used 556 when transmitting NHRP messages. Additionally, where a protocol has 557 valid short and long forms of identification, receivers MAY choose 558 to recognise the long form. 560 ar$hopcnt 561 The Hop count indicates the maximum number of NHSs that an NHRP 562 packet is allowed to traverse before being discarded. 564 ar$pktsz 565 The total length of the NHRP packet, in octets (exluding link layer 566 encapsulation). 568 ar$chksum 569 The standard IP checksum over the entire NHRP packet (starting with 570 the fixed header). If only the hop count field is changed, the 571 checksum is adjusted without full recomputation. The checksum is 572 completely recomputed when other header fields are changed. 574 ar$extoff 575 This field identifies the existence and location NHRP extensions. 576 If this field is 0 then no extensions exist otherwise this field 577 represents the offset from the beginning of the NHRP packet (i.e., 578 starting from the ar$afn field) of the first extension. 580 ar$op.version 581 This field is set to 0x0001 for NHRP version 1. 583 ar$op.type 584 This is the NHRP packet type (request, reply, purge, or error). 586 ar$shtl 587 Type & length of source NBMA address interpreted in the context of 588 the 'hardware' (NBMA media) indicated by ar$afn (e.g., 589 ar$afn=0x0003 for ATM). 591 ar$sstl 592 Type & length of source NBMA subaddress interpreted in the context 593 of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 594 ar$afn=0x0003 for ATM). When an NBMA technology has no concept of 595 a subaddress the subaddress is always null and ar$sstl = 0 and no 596 storage is allocated for the address in the appropriate mandatory 597 part. 599 The ar$shtl and ar$sstl fields are coded as follows: 601 7 6 5 4 3 2 1 0 602 +-+-+-+-+-+-+-+-+ 603 |0|x| length | 604 +-+-+-+-+-+-+-+-+ 606 The most significant bit is reserved and MUST be set to zero. The 607 second most significant bit (x) is a flag indicating whether the NBMA 608 address being referred to is in: 610 - NSAP format (x = 0). 611 - Native E.164 format (x = 1). 613 For NBMA technologies that use neither NSAP nor E.164 format 614 addresses, x = 0 SHALL be used to indicate the native form for the 615 particular NBMA technology. 617 The bottom 6 bits is an unsigned integer value indicating the length 618 of the associated NBMA address in octets. If this value is zero the 619 flag x is ignored. 621 5.2 Mandatory Part 623 The Mandatory Part of the NHRP packet contains the operation specific 624 information (e.g., Next Hop Resolution request/reply, etc.) and 625 variable length data which is pertinent to the packet type. 627 5.2.1 Next Hop Resolution Request 629 The Next Hop Resolution Request packet has a Type code of 1. The 630 Mandatory Part has the following format: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Request ID | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 |Q|A|P|B| Unused| Proto Length | Source Address Holding Time | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | unused | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Source NBMA Address (variable length) | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Source NBMA Subaddress (variable length) | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Source Protocol Address (variable length) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Destination Protocol Address (variable length) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Request ID 651 A value which, when coupled with the address of the source, 652 provides a unique identifier for the information contained in a 653 Request and its associated Next Hop Resolution Reply, and any 654 subsequent Purge. This value can be used by the source to aid in 655 matching requests with replies. This value could also be sent 656 across a virtual circuit (in SVC environments) to aid in matching 657 NHRP transactions with virtual circuits (this use is for further 658 study). 660 The value is taken from a 32 bit counter that is incremented each 661 time a new NHRP request is transmitted. The same value MUST be 662 used when sending another request for the same destination when a 663 previous request is still active or pending, i.e., when 664 retransmitting a Next Hop Resolution Request because a Next Hop 665 Resolution Reply was not received, or when refreshing an existing 666 entry to avoid holding timer expiration. A new value MUST be used 667 when sending a request when no cache entry is present, or a 668 previous cache entry was deleted for any reason. 670 Next Hop Resolution Request Flags 672 Q 673 Set if the requester is a router; clear if the requester is a 674 host. 676 A 677 A response to an NHRP request may contain cached information. If 678 an authoritative answer is desired, then this bit 679 ("Authoritative") should be set. If non-authoritative (cached) 680 information is acceptable, this bit should be clear. 682 P 683 Unused (clear on transmit) 685 B 686 Unused (clear on transmit) 688 Proto Length 689 The length in octets, of the internetwork layer protocol addresses 690 appearing in this packet. If this length is not a multiple of 4, 691 each internetwork layer address is zero-filled to the nearest 32- 692 bit boundary. 694 Source Address Holding Time 695 The Source Address Holding Time field specifies the number of 696 seconds for which the source NBMA information is considered to be 697 valid. Cached information SHALL be discarded when the holding time 698 expires. 700 Source NBMA Address 701 The Source NBMA address field is the address of the source station 702 which initiated the request. It is zero-filled to the nearest 32- 703 bit boundary. However, if its length as specified in ar$shtl is 0 704 then no storage is allocated for this address at all. 706 Source NBMA SubAddress 707 The Source NBMA subaddress field is the address of the source 708 station which initiated the request. It is zero-filled to the 709 nearest 32- bit boundary. However, if its length as specified in 710 ar$sstl is 0 then no storage is allocated for this address at all. 712 Source Protocol Addresses 713 This is the protocol address of the station which initially issued 714 an NHRP Request packet. 716 Destination Protocol Address 717 This is the protocol address of the station for which the NBMA next 718 hop is desired. 720 (The NBMA address/subaddress form allows combined E.164/NSAPA form of 721 NBMA addressing. For NBMA technologies without a subaddress concept, 722 the subaddress field is always ZERO length and ar$sstl = 0.) 724 5.2.2 NHRP Next Hop Resolution Reply 726 The NHRP Next Hop Resolution Reply packet has a type code of 2. The 727 Mandatory Part has the following format: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Request ID | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 |Q|A|P|B| Unused| Proto Length | Next Hop Holding Time | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | NH Addr T/L | NH SAddr T/L | Preference | unused | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Source NBMA Address (variable length) | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Source NBMA Subaddress (variable length) | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Source Protocol Address (variable length) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Destination Protocol Address (variable length) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Next Hop Protocol Address (variable length) | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Next Hop NBMA Address (variable length) | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Next Hop NBMA Subaddress (variable length) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Request ID 754 A value which, when coupled with the address of the source, 755 provides a unique identifier for the information contained in a 756 Request and its associated Next Hop Resolution Reply, and any 757 subsequent Purge. This value can be used by the source to aid in 758 matching requests with replies. This value could also be sent 759 across a virtual circuit (in SVC environments) to aid in matching 760 NHRP transactions with virtual circuits (this use is for further 761 study). 763 The value is taken from a 32 bit counter that is incremented each 764 time a new NHRP request is transmitted. The same value MUST be 765 used when sending another request for the same destination when a 766 previous request is still active or pending, i.e., when 767 retransmitting a Next Hop Resolution Request because a Next Hop 768 Resolution Reply was not received, or when refreshing an existing 769 entry to avoid holding timer expiration. A new value MUST be used 770 when sending a request when no cache entry is present, or a 771 previous cache entry was deleted for any reason. 773 Next Hop Resolution Request Flags 775 Q 776 Copied from the Next Hop Resolution Request. Set if the 777 Requester is a router; clear if the requester is a host. 779 A 780 Set if the next hop in the Next Hop Resolution Reply is 781 authoritative; clear if the Next Hop Resolution Reply is non- 782 authoritative. 784 P 785 Set if the Next Hop Resolution Reply is positive; clear if the 786 Next Hop Resolution Reply is negative. 788 B 789 Set if the association between the destination and the next hop 790 information is guaranteed to be stable for the lifetime of the 791 information (the holding time). This is the case if the Next Hop 792 protocol address identifies the destination (though it may be 793 different in value than the Destination address if the 794 destination system has multiple addresses) or if the destination 795 is not connected directly to the NBMA subnetwork but the egress 796 router to that destination is guaranteed to be stable (such as 797 when the destination is immediately adjacent to the egress router 798 through a non-NBMA interface). This information affects cacheing 799 strategies (see section 6.2). 801 An NHS is not allowed to reply to an Next Hop Resolution Request 802 for authoritative information with cached information, but may do 803 so for an NHRP Next Hop Resolution Request which indicates a 804 request for non-authoritative information. An NHS may reply to an 805 Next Hop Resolution Request for non-authoritative information 806 with authoritative information. 808 Proto Length 809 The length in octets, of the internetwork layer protocol addresses 810 appearing in this packet. If this length is not a multiple of 4, 811 each internetwork layer address is zero-filled to the nearest 32- 812 bit boundary. 814 Next Hop Address Holding Time 815 The Next Hop Address Holding Time field specifies the number of 816 seconds for which the next hop NBMA information is considered to be 817 valid. Cached information SHALL be discarded when the holding time 818 expires. Must be set to 0 on a NAK. 820 NH Addr T/L 821 Type & length of next hop NBMA address interpreted in the context 822 of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 823 ar$afn=0x0003 for ATM). When the address length is specified as 0 824 no storage is allocated for the address. Set to 0 on a NAK. 826 NH SAddr T/L 827 Type & length of next hop NBMA subaddress interpreted in the 828 context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 829 ar$afn=0x0003 for ATM). When an NBMA technology has no concept of 830 a subaddress the subaddress is always null with a length of 0. 831 When the address length is specified as 0 no storage is allocated 832 for the address. Set to 0 on a NAK. 834 Preference 835 This field specifies the preference of the Next Hop entry, relative 836 to other Next Hop entries in this NHRP Next Hop Resolution Reply 837 packet which may be in the Additional Next Hop Entries Extension 838 for the given internetworking protocol. Higher values indicate 839 more preferable Next Hop entries. Action taken when multiple next 840 hop entries have the highest preference value is a local matter. 841 Set to 0 on a NAK. 843 Source NBMA Address 844 The Source NBMA address field is the address of the source station 845 which initiated the request. It is zero-filled to the nearest 32- 846 bit boundary. However, if its length as specified in ar$shtl is 0 847 then no storage is allocated for this address at all. 849 Source NBMA SubAddress 850 The Source NBMA subaddress field is the address of the source 851 station which initiated the request. It is zero-filled to the 852 nearest 32- bit boundary. However, if its length as specified in 853 ar$sstl is 0 then no storage is allocated for this address at all. 855 Source Protocol Addresses 856 This is the protocol address of the station which initially issued 857 an NHRP Request packet. 859 Destination Protocol Address 860 This is the protocol address of the station for which the NBMA next 861 hop is desired. 863 (The NBMA address/subaddress form allows combined E.164/NSAPA form 864 of NBMA addressing. For NBMA technologies without a subaddress 865 concept, the subaddress field is always ZERO length and ar$sstl = 866 0.) 868 Next Hop entry 870 Next Hop Protocol Address 871 This internetworkin layer address specifies the next hop. This 872 will be the address of the destination host if it is directly 873 attached to the NBMA subnetwork, or the egress router if it is 874 not directly attached. 876 Next Hop NBMA Address 877 This is the NBMA address of the station that is the next hop for 878 packets bound for the internetworking layer address specified. 879 The NBMA address field itself is zero-filled to the nearest 32- 880 bit boundary. 882 Next Hop NBMA SubAddress 883 This is the NBMA sub address of the station that is the next hop 884 for packets bound for the internetworking layer address 885 specified. The NBMA subaddress field itself is zero-filled to 886 the nearest 32-bit boundary. 888 There may be multiple Next Hop entries returned in the Next Hop 889 Resolution Reply by including the Additional Next Hop Entries 890 Extension. See Section 5.3.9 for use of these entries. The most 891 preferable Next Hop must be specified in the mandatory part of the 892 Next Hop Resolution Reply. 894 Any extensions present in the Next Hop Resolution Request packet MUST 895 be present in the NHRP Next Hop Resolution Reply packet, except for 896 the case of unrecognized non-Compulsory extensions. 898 If an unsolicited NHRP Next Hop Resolution Reply packet is received, 899 an Error Indication of type Invalid Next Hop Resolution Reply 900 Received SHOULD be sent in response. 902 5.2.3 NHRP Registration Request 904 The NHRP Registration Request is sent from a station to an NHS to 905 notify the NHS of the station's NBMA information. It has a Type code 906 of 3. The Mandatory Part has the following format: 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Request ID | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Unused | Proto Length | Register Holding Time | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | unused | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Source NBMA Address (variable length) | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Source NBMA Subaddress (variable length) | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Source Protocol Address (variable length) | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Destination Protocol Address (variable length) | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Request ID 927 A value which, when coupled with the address of the source, 928 provides a unique identifier for the information contained in a 929 Registration Request packet. This value is copied directly from a 930 Registration Request packet into the associated Registration Reply. 931 This value could also be sent across a virtual circuit (in SVC 932 environments) to aid in matching NHRP transactions with virtual 933 circuits (this use is for further study). 935 Proto Length 936 The length in octets, of the internetwork layer protocol addresses 937 appearing in this packet. If this length is not a multiple of 4, 938 each internetwork layer address is zero-filled to the nearest 32- 939 bit boundary. 941 Source Protocol Address 942 The Protocol Address of the station wishing to register its NBMA 943 address with an NHS. 945 Register Holding Time 946 The Register Holding Time field specifies the number of seconds for 947 which the registered NBMA information is considered to be valid. 948 Cached information SHALL be discarded when the holding time 949 expires. 951 Source NBMA Address 952 The Source NBMA address field is the address of the source station 953 which initiated the request. It is zero-filled to the nearest 32- 954 bit boundary. However, if its length as specified in ar$shtl is 0 955 then no storage is allocated for this address at all. 957 Source NBMA SubAddress 958 The Source NBMA subaddress field is the address of the source 959 station which initiated the request. It is zero-filled to the 960 nearest 32- bit boundary. However, if its length as specified in 961 ar$sstl is 0 then no storage is allocated for this address at all. 963 Source Protocol Addresses 964 This is the protocol address of the station which initially issued 965 an NHRP Request packet. 967 Destination Protocol Address 968 This is the protocol address of the NHS for which the source NBMA 969 next hop information is being reistered 971 This packet is used to register a station's Protocol and NBMA 972 addresses with its NHSs, as configured or known through conventional 973 routing means. This allows static configuration information to be 974 reduced; the NHSs need not be configured with the identities of all 975 of the stations that they serve. 977 It is possible that a misconfigured station will attempt to register 978 with the wrong NHS (i.e., one that cannot serve it due to policy 979 constraints or routing state). If this is the case, the NHS MUST 980 reply with a NAK-ed Registration Reply of type Can't Serve This 981 Address. 983 If an NHS cannot serve a station due to a lack of resources, the NHS 984 MUST reply with a NAK-ed Registration Reply of type Registration 985 Overflow. 987 In order to keep the registration entry from being discarded, the 988 station MUST resend the NHRP Registration Request packet often enough 989 to refresh the registration, even in the face of occasional packet 990 loss. It is recommended that the Registration Request packet be sent 991 at an interval equal to one-third of the Holding Time specified 992 therein. 994 5.2.4 NHRP Registration Reply 996 The NHRP Registration Reply is sent by an NHS to a client in response 997 to that client's Registration Request. If the NAK Code field has 998 anything other than 0 zero in it then the Registration Reply is a NAK 999 otherwise the reply is an ACK. The Registration Reply has a Type 1000 code of 4. Its mandatory part has the following format: 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Request ID | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | NAK Code | Proto Length | Register Holding Time | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | unused | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Source NBMA Address (variable length) | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Source NBMA Subaddress (variable length) | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Source Protocol Address (variable length) | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Destination Protocol Address (variable length) | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 Request ID 1021 A value which, when coupled with the address of the source, 1022 provides a unique identifier for the information contained in a 1023 Registration Request packet. This value is copied directly from a 1024 Registration Request packet into the associated Registration Reply. 1025 This value could also be sent across a virtual circuit (in SVC 1026 environments) to aid in matching NHRP transactions with virtual 1027 circuits (this use is for further study). 1029 NAK Code 1030 If this field is set to zero then this packet contains a 1031 Registration Request Acknowledgement. If this field contains any 1032 other value then this contains a Registration Request NAK. 1033 Currently defined NAK Codes are as follows: 1035 4 - Can't Serve This Address 1037 An NHS may refuse an NHRP registration attempt for 1038 administrative reasons. If so, the NHS MUST reply with this 1039 NAK in the Registration Reply which contains a NAK code of 4. 1041 5 - Registration Overflow 1043 If an NHS cannot serve a station due to a lack of resources, 1044 the NHS MUST reply with a NAKed Registration Reply which 1045 contains a NAK code of 5. 1047 Proto Length 1048 The length in octets, of the internetwork layer protocol addresses 1049 appearing in this packet. If this length is not a multiple of 4, 1050 each internetwork layer address is zero-filled to the nearest 32- 1051 bit boundary. 1053 Source Protocol Address 1054 The Protocol Address of the client that sent a Registration 1055 Request. 1057 Register Holding Time 1058 The Register Holding Time field specifies the number of seconds for 1059 which the registered NBMA information is considered to be valid. 1060 Cached information SHALL be discarded when the holding time 1061 expires. 1063 Source NBMA Address 1064 The Source NBMA address field is the address of the source station 1065 which initiated the request. It is zero-filled to the nearest 32- 1066 bit boundary. However, if its length as specified in ar$shtl is 0 1067 then no storage is allocated for this address at all. 1069 Source NBMA SubAddress 1070 The Source NBMA subaddress field is the subaddress of the source 1071 station which initiated the request. It is zero-filled to the 1072 nearest 32-bit boundary. However, if its length as specified in 1073 ar$sstl is 0 then no storage is allocated for this address at all. 1075 Source Protocol Addresses 1076 This is the protocol address of the station which initially issued 1077 an NHRP request packet. 1079 Destination Protocol Address 1080 This is the protocol address of the station for which the NBMA next 1081 hop is desired. 1083 This packet is used to register a station's Protocol and NBMA 1084 addresses with its neighboring NHSs, as configured or known through 1085 conventional routing means. This allows static configuration 1086 information to be reduced; the NHSs need not be configured with the 1087 identities of all of the stations that they serve. 1089 It is possible that a misconfigured station will attempt to register 1090 with the wrong NHS (i.e., one that cannot serve it due to policy 1091 constraints or routing state). If this is the case, the NHS MUST 1092 reply with a NAK-ed Registration Reply of type Can't Serve This 1093 Address. 1095 If an NHS cannot serve a station due to a lack of resources, the NHS 1096 MUST reply with a NAK-ed Registration Reply of type Registration 1097 Overflow. 1099 In order to keep the registration entry from being discarded, the 1100 station MUST resend the NHRP Registration Request packet often enough 1101 to refresh the registration, even in the face of occasional packet 1102 loss. It is recommended that the Registration Request packet be sent 1103 at an interval equal to one-third of the Holding Time specified 1104 therein. 1106 5.2.5 NHRP Purge 1108 The NHRP Purge packet has a type code of 5. The Mandatory Part has 1109 the following format: 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | unused | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 |A| Unused | Proto Length | unused | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | unused | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Source NBMA Address (variable length) | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Source NBMA Subaddress (variable length) | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Source Protocol Address (variable length) | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Destination Protocol Address (variable length) | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Target Protocol Address (variable length) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 A 1132 Clear if this is a purge request, set if this is an acknowledgment. 1134 Proto Length 1135 The length in octets, of the internetwork layer protocol addresses 1136 appearing in this packet. If this length is not a multiple of 4, 1137 each internetwork layer address is zero-filled to the nearest 32- 1138 bit boundary. 1140 Source NBMA Address 1141 The Source NBMA address field is the address of the source station 1142 which initiated the Purge. It is zero-filled to the nearest 32- 1143 bit boundary. However, if its length as specified in ar$shtl is 0 1144 then no storage is allocated for this address at all. 1146 Source NBMA SubAddress 1147 The Source NBMA subaddress field is the address of the source 1148 station which initiated the Purge. It is zero-filled to the 1149 nearest 32- bit boundary. However, if its length as specified in 1150 ar$sstl is 0 then no storage is allocated for this address at all. 1152 Source Protocol Address 1153 The address of the station which is sending the purge notification. 1155 Destination Protocol Address 1156 The address of the station that will be receiving the purge 1157 notification. 1159 Target Protocol Address 1160 The address which is to be purged from the receiver's database. 1162 An NHRP Purge request packet is sent from an NHS to a station to 1163 cause it to delete previously cached information. This is done when 1164 the information may be no longer valid (typically when the NHS has 1165 previously provided next hop information for a station that is not 1166 directly connected to the NBMA subnetwork, and the egress point to 1167 that station may have changed). 1169 An NHRP Purge request packet may also be sent from a client to an NHS 1170 with which the client had previously sent a registration packet to. 1171 This allows for a client to invalidate an NHRP registration before it 1172 would otherwise expire. 1174 The station sending the NHRP Purge request MUST periodically 1175 retransmit the request until it is acknowledged, or until the holding 1176 time of the information being purged has expired. Retransmission 1177 strategies are for further investigation. 1179 When a station receives an NHRP Purge request, it MUST discard any 1180 previous cached information that matches the Target Protocol Address. 1182 An acknowledgment MUST be returned for the Purge request even if the 1183 station does not have a matching cache entry. The acknowledgment is 1184 constructed by setting the Acknowledgment (A) bit and returning the 1185 Purge request to the Source Protocol Address. 1187 If the station wishes to reestablish communication with the 1188 destination shortly after receiving a Purge request, it should make 1189 an authoritative request in order to avoid any stale cache entries 1190 that might be present in intermediate NHSs. (See section 6.2.2.) It 1191 is recommended that authoritative Next Hop Resolution Requests be 1192 made for the duration of the holding time of the old information. 1194 5.2.6 NHRP Error Indication 1196 The NHRP Error Indication is used to convey error indications to the 1197 sender of an NHRP packet. It has a type code of 6. The Mandatory 1198 Part has the following format: 1200 0 1 2 3 1201 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 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Error Code | Error Offset | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Unused | Proto Length | | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | unused | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | Source NBMA Address (variable length) | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Source NBMA Subaddress (variable length) | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 | Source Protocol Address (variable length) | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Destination Protocol Address (variable length) | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Contents of NHRP Packet in error (variable length) | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 Error Code 1221 An error code indicating the type of error detected, chosen from 1222 the following list: 1224 1 - Unrecognized Extension 1226 When the Compulsory bit of an extension is set, the NHRP 1227 request cannot be satisfied unless the extension is processed. 1228 The responder MUST return an Error Indication of type 1229 Unrecognized Extension if it is incapable of processing the 1230 extension. However, if a transit NHS (one which is not going 1231 to generate a reply) detects an unrecognized extension, it 1232 SHALL ignore the extension. 1234 2 - Subnetwork ID Mismatch 1236 This error occurs when the current station receives an NHRP 1237 packet whose NBMA subnetwork identifier matches none of the 1238 locally known identifiers for the NBMA subnetwork on which the 1239 packet is received. 1241 3 - NHRP Loop Detected 1243 A Loop Detected error is generated when it is determined that 1244 an NHRP packet is being forwarded in a loop. 1246 8 - NHRP SDU Size Exceeded 1248 If the SDU size of the NHRP packet exceeds the maximum SDU size 1249 of the NBMA network, this error is returned. 1251 9 - Invalid Extension 1253 If an NHS finds an extension in a packet which is inappropriate 1254 for the packet type, an error is sent back to the sender with 1255 Invalid Extension as the code. 1257 10- Invalid Next Hop Resolution Reply Received 1259 If a client receives a Next Hop Resolution Reply for a Next Hop 1260 Resolution Request which it believes it did not make then an 1261 error packet is sent to the station making the reply with an 1262 error code of Invalid Reply Received. 1264 Error Offset 1265 The offset in octets into the original NHRP packet, starting at the 1266 NHRP Fixed Header, at which the error was detected. 1268 Proto Length 1269 The length in octets, of the internetwork layer protocol addresses 1270 appearing in this packet. If this length is not a multiple of 4, 1271 each internetwork layer address is zero-filled to the nearest 32- 1272 bit boundary. 1274 Source NBMA Address 1275 The Source NBMA address field is the address of the source station 1276 which observed the error. It is zero-filled to the nearest 32- bit 1277 boundary. However, if its length as specified in ar$shtl is 0 then 1278 no storage is allocated for this address at all. 1280 Source NBMA SubAddress 1281 The Source NBMA subaddress field is the address of the source 1282 station which observed the error. It is zero-filled to the nearest 1283 32- bit boundary. However, if its length as specified in ar$sstl is 1284 0 then no storage is allocated for this address at all. 1286 Source Protocol Addresses 1287 This is the protocol address of the station which issued the Error 1288 packet. 1290 Destination Protocol Address 1291 This is the protocol address of the station for which the NBMA next 1292 hop is desired. However, if its length as specified in Proto Length 1293 is set to 0 then no storage is allocated for this address at all. 1295 An Error Indication packet SHALL NEVER be generated in response to 1296 another Error Indication packet. When an Error Indication packet is 1297 generated, the offending NHRP packet SHALL be discarded. In no case 1298 should more than one Error Indication packet be generated for a 1299 single NHRP packet. 1301 5.3 Extensions Part 1303 The Extensions Part, if present, carries one or more extensions in 1304 {Type, Length, Value} triplets. Extensions are only present in a 1305 Reply if they were present in the corresponding Request; therefore, 1306 minimal NHRP station implementations that do not act as an NHS and do 1307 not transmit extensions need not be able to receive them. An 1308 implementation that is incapable of processing extensions SHALL 1309 return an Error Indication of type Unrecognized Extension when it 1310 receives an NHRP packet containing extensions. 1312 Extensions are typically protocol-specific, as noted. 1314 Extensions have the following format: 1316 0 1 2 3 1317 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 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 |C|u| Type | Length | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | Value... | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 C 1325 "Compulsory." If clear, and the NHS does not recognize the type 1326 code, the extension may safely be ignored. If set, and the NHS 1327 does not recognize the type code, the NHRP request is considered to 1328 be in error. (See below for details.) 1330 u 1331 Unused and must be set to zero. 1333 Type 1334 The extension type code (see below). The extension type is not 1335 qualified by the Compulsory bit, but is orthogonal to it. 1337 Length 1338 The length in octets of the value (not including the Type and 1339 Length fields; a null extension will have only an extension header 1340 and a length of zero). 1342 Each extension is padded with zero octets to a 32 bit boundary. This 1343 padding is not included in the Length field. 1345 When extnsions exist, extensions list is terminated by the Null TLV, 1346 having Type = 0 and Length = 0. 1348 Extensions may occur in any order, but any particular extension type 1349 (other than the vendor-private extension) may occur only once in an 1350 NHRP packet. The vendor-private extension may occur multiple times 1351 in a packet, to allow for extensions which do not share the same 1352 vendor ID to be represented. 1354 The Compulsory bit provides for a means to add to the extension set. 1355 If the bit is set, the NHRP request cannot be satisfied unless the 1356 extension is processed, so the responder MUST return an Error 1357 Indication of type Unrecognized Extension. If the bit is clear, the 1358 extension can be safely ignored, though unrecognized extensions so 1359 ignored that were received in an NHRP Request packet MUST be returned 1360 unchanged in the corresponding NHRP Reply. 1362 If a transit NHS (one which is not going to generate a reply) detects 1363 an unrecognized extension, it SHALL ignore the extension. If the 1364 Compulsory bit is set, the transit NHS MUST NOT cache the information 1365 (in the case of a reply) and MUST NOT identify itself as an egress 1366 router (in the Forward Record or Reverse Record extensions). 1367 Effectively, this means that a transit NHS that encounters an 1368 extension that it cannot process and determines that the Compulsory 1369 bit is set MUST NOT participate in any way in the protocol exchange, 1370 other than acting as a forwarding agent for the request. 1372 5.3.1 Destination Prefix Extension 1374 Compulsory = 0 1375 Type = 1 1376 Length = 1 1378 This extension is used to indicate that the information carried in an 1379 NHRP Reply pertains to an equivalence class of destinations rather 1380 than just the destination Protocol address specified in the request. 1382 All addresses that match the destination Protocol address in the bit 1383 positions for which the mask has a one bit are part of the 1384 equivalence class. 1386 0 1 2 3 1387 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 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Destination Mask (variable lenfth) | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 The size of the mask in number of octets is obtained through the 1393 "Proto Length" in the Mandatory Part of packet. 1395 For example, in the case of IPv4, if an initiator would like to 1396 receive this equivalence information, it SHALL add this extension to 1397 the NHRP Request with a value of 255.255.255.255. The responder 1398 SHALL copy the extension to the NHRP Reply and modify the mask 1399 appropriately. 1401 5.3.2 NBMA Subnetwork ID Extension 1403 Compulsory = 1 1404 Type = 2 1405 Length = variable 1407 This extension is used to carry one or more identifiers for the NBMA 1408 subnetwork. This can be used as a validity check to ensure that the 1409 request does not leave a particular NBMA subnetwork. The extension 1410 is placed in an NHRP Request packet by the initiator with an ID value 1411 of zero; the first NHS fills in the field with the identifier(s) for 1412 the NBMA subnetwork. 1414 Multiple NBMA Subnetwork IDs may be used as a transition mechanism 1415 while NBMA Subnetworks are being split or merged. 1417 0 1 2 3 1418 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 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | NBMA Subnetwork ID | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 ... 1424 Each identifier consists of a 32 bit globally unique value assigned 1425 to the NBMA subnetwork. This value should be chosen from the IP 1426 address space administered by the operators of the NBMA subnetwork. 1427 This value is used for identification only, not for routing or any 1428 other purpose. 1430 Each NHS processing an NHRP Request SHALL verify these values. If 1431 none of the values matches the NHS's NBMA Subnetwork ID, the NHS 1432 SHALL return an Error Indication of type "Subnetwork ID Mismatch" and 1433 discard the NHRP Request. 1435 When an NHS is building an NHRP Reply and the NBMA Subnetwork ID 1436 extension is present in the NHRP Request, the NBMA Subnetwork ID 1437 extension SHALL be copied from the Request to the Reply, including 1438 all values carried therein. 1440 Each NHS processing an NHRP Reply SHALL verify the values carried in 1441 the NBMA Subnetwork ID extension, if present. If none of the values 1442 matches the NHSs NBMA Subnetwork ID, the NHS SHALL return an Error 1443 Indication of type "Subnetwork ID Mismatch" and discard the NHRP 1444 Reply. 1446 5.3.3 Responder Address Extension 1448 Compulsory = 1 1449 Type = 3 1450 Length = 4 1452 This extension is used to determine the Protocol address of the NHRP 1453 Responder, that is, the entity that generates the NHRP Reply packet. 1454 The intent is to identify the entity responding to the request, which 1455 may be different (in the case of cached replies) than the system 1456 identified in the Next Hop field of the reply, and to aid in 1457 detecting loops in the NHRP forwarding path. 1459 0 1 2 3 1460 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 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Responder's Protocol Address | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 The size of the Responder's Protocol Address in octets is obtained 1466 through the "Proto Length" in the Mandatory Part of packet. 1468 If a requester desires this information, it SHALL include this 1469 extension, with a value of zero, in the NHRP Request packet. 1471 If an NHS is generating an NHRP Reply packet in response to a request 1472 containing this extension, it SHALL include this extension, 1473 containing its Protocol address, in the NHRP Reply. If an NHS has 1474 more than one Protocol address, it SHALL use the same Protocol 1475 address consistently in all of the Responder Address, Forward NHS 1476 Record, and Reverse NHS Record extensions. The choice of which of 1477 several Protocol addresses to include in this extension is a local 1478 matter. 1480 If an NHRP Next Hop Resolution Reply packet being forwarded by an NHS 1481 contains an Protocol address of that NHS in the Responder Address 1482 Extension, the NHS SHALL generate an Error Indication of type "NHRP 1483 Loop Detected" and discard the Next Hop Resolution Reply. 1485 If an NHRP Next Hop Resolution Reply packet is being returned by an 1486 intermediate NHS based on cached data, it SHALL place its own 1487 address in this extension (differentiating it from the address in the 1488 Next Hop field). 1490 5.3.4 NHRP Forward NHS Record Extension 1492 Compulsory = 1 1493 Type = 4 1494 Length = variable 1496 The NHRP forward NHS record is a list of NHSs through which an NHRP 1497 request traverses. Each NHS SHALL append a Next Hop element 1498 containing its Protocol address to this extension. 1500 In addition, NHSs that are willing to act as egress routers for 1501 packets from the source to the destination SHALL include information 1502 about their NBMA Address. 1504 0 1 2 3 1505 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 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Unused | Proto Length | Holding Time | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | NHS Addr T/L | NHS SAddr T/L| unused | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Protocol Address (variable length) | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | Next Hop NBMA Address (variable length) | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Next Hop NBMA Subaddress (variable length) | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 Proto Length 1519 The length in octets, of the internetwork layer protocol addresses 1520 appearing in this packet. If this length is not a multiple of 4, 1521 each internetwork layer address is zero-filled to the nearest 32- 1522 bit boundary. 1524 Holding Time 1525 The Holding Time field specifies the number of seconds for which 1526 the NBMA information is considered to be valid. Cached information 1527 SHALL be discarded when the holding time expires. Must be set to 0 1528 on a NAK. 1530 NHS Addr T/L 1531 Type & length of transit NHS's NBMA address interpreted in the 1532 context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 1533 ar$afn=0x0003 for ATM). When the address length is specified as 0 1534 no storage is allocated for the address. Set to 0 on a NAK. 1536 NHS SAddr T/L 1537 Type & length of transit NHS's NBMA subaddress interpreted in the 1538 context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 1539 ar$afn=0x0003 for ATM). When an NBMA technology has no concept of 1540 a subaddress the subaddress is always null with a length of 0. 1541 When the address length is specified as 0 no storage is allocated 1542 for the address. Set to 0 on a NAK. 1544 NHS Protocol Address 1545 This internetworkin layer address specifies the transit NHS. This 1546 will be the address of the destination host if it is directly 1547 attached to the NBMA subnetwork, or the egress router if it is not 1548 directly attached. 1550 NHS NBMA Address 1551 This is the NBMA address of the station that is the transit NHS for 1552 packets bound for the internetworking layer address specified. The 1553 NBMA address field itself is zero-filled to the nearest 32-bit 1554 boundary. 1556 NHS NBMA SubAddress 1557 This is the NBMA sub address of the station that is the transit NHS 1558 for packets bound for the internetworking layer address specified. 1559 The NBMA subaddress field itself is zero-filled to the nearest 32- 1560 bit boundary. 1562 If a requester wishes to obtain this information, it SHALL include 1563 this extension with a length of zero. 1565 Each NHS SHALL append an appropriate Next Hop element to this 1566 extension when processing an NHRP Request. The extension length 1567 field and NHRP checksum SHALL be adjusted as necessary. 1569 The last Hop NHS (the one that will be generating the NHRP Reply) 1570 SHALL NOT update this extension (since this information will be in 1571 the reply). 1573 If an NHS has more than one Protocol address, it SHALL use the same 1574 Protocol address consistently in all of the Responder Address, 1575 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1576 which of several Protocol addresses to include in this extension is a 1577 local matter. 1579 If an NHRP Request packet being forwarded by an NHS contains the 1580 Protocol address of that NHS in the Forward NHS Record Extension, the 1581 NHS SHALL generate an Error Indication of type "NHRP Loop Detected" 1582 and discard the Request. 1584 5.3.5 NHRP Reverse NHS Record Extension 1586 Compulsory = 1 1587 Type = 5 1588 Length = variable 1590 The NHRP reverse NHS record is a list of NHSs through which an NHRP 1591 reply traverses. Each NHS SHALL append a Next Hop element containing 1592 its Protocol address to this extension. 1594 In addition, NHSs that are willing to act as egress routers for 1595 packets from the source to the destination SHALL include information 1596 about their NBMA Address. 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 | Proto Length | Holding Time | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | NHS Addr T/L | NHS SAddr T/L| unused | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Protocol Address (variable length) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | Next Hop NBMA Address (variable length) | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | Next Hop NBMA Subaddress (variable length) | 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 Proto Length 1613 The length in octets, of the internetwork layer protocol addresses 1614 appearing in this packet. If this length is not a multiple of 4, 1615 each internetwork layer address is zero-filled to the nearest 32- 1616 bit boundary. 1618 Holding Time 1619 The Holding Time field specifies the number of seconds for which 1620 the NBMA information is considered to be valid. Cached information 1621 SHALL be discarded when the holding time expires. Must be set to 0 1622 on a NAK. 1624 NHS Addr T/L 1625 Type & length of transit NHS's NBMA address interpreted in the 1626 context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 1627 ar$afn=0x0003 for ATM). When the address length is specified as 0 1628 no storage is allocated for the address. Set to 0 on a NAK. 1630 NHS SAddr T/L 1631 Type & length of transit NHS's NBMA subaddress interpreted in the 1632 context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 1633 ar$afn=0x0003 for ATM). When an NBMA technology has no concept of 1634 a subaddress the subaddress is always null with a length of 0. 1635 When the address length is specified as 0 no storage is allocated 1636 for the address. Set to 0 on a NAK. 1638 NHS Protocol Address 1639 This internetworkin layer address specifies the transit NHS. This 1640 will be the address of the destination host if it is directly 1641 attached to the NBMA subnetwork, or the egress router if it is not 1642 directly attached. 1644 NHS NBMA Address 1645 This is the NBMA address of the station that is the transit NHS for 1646 packets bound for the internetworking layer address specified. The 1647 NBMA address field itself is zero-filled to the nearest 32-bit 1648 boundary. 1650 NHS NBMA SubAddress 1651 This is the NBMA sub address of the station that is the transit NHS 1652 for packets bound for the internetworking layer address specified. 1653 The NBMA subaddress field itself is zero-filled to the nearest 32- 1654 bit boundary. 1656 If a requester wishes to obtain this information, it SHALL include 1657 this extension with a length of zero. 1659 Each NHS SHALL append an appropriate Next Hop element to this 1660 extension when processing an NHRP Reply. The extension length field 1661 and NHRP checksum SHALL be adjusted as necessary. 1663 The NHS generating the NHRP Reply SHALL NOT update this extension. 1665 If an NHS has more than one Protocol address, it SHALL use the same 1666 Protocol address consistently in all of the Responder Address, 1667 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1668 which of several Protocol addresses to include in this extension is a 1669 local matter. 1671 If an NHRP Reply packet being forwarded by an NHS contains the 1672 Protocol address of that NHS in the Reverse NHS Record Extension, the 1673 NHS SHALL generate an Error Indication of type "NHRP Loop Detected" 1674 and discard the Reply. 1676 Note that this information may be cached at intermediate NHSs; if 1677 so, the cached value SHALL be used when generating a reply. Note 1678 that the Responder Address extension may be used to disambiguate the 1679 set of NHSs that actually processed the reply. 1681 5.3.6 NHRP QoS Extension 1683 Compulsory = 0 1684 Type = 6 1685 Length = variable 1687 The NHRP QoS Extension is carried in NHRP Request packets to indicate 1688 the desired QoS of the path to the indicated destination. This 1689 information may be used to help select the appropriate NBMA next hop. 1691 It may also be carried in NHRP Register packets to indicate the QoS 1692 to which the registration applies. 1694 The syntax and semantics of this extension are TBD; alignment with 1695 resource reservation may be useful. 1697 5.3.7 NHRP Authentication Extension 1699 Compulsory = 1 1700 Type = 7 1701 Length = variable 1703 The NHRP Authentication Extension is carried in NHRP packets to 1704 convey authentication information between NHRP speakers. The 1705 Authentication Extension may be included in any NHRP packet type. 1707 Authentication is done pairwise on an NHRP hop-by Hop basis; the 1708 authentication extension is regenerated on each hop. If a received 1709 packet fails the authentication test, the NHS SHALL generate an Error 1710 Indication of type "Authentication Failure" and discard the packet. 1711 In no case SHALL an Error Indication packet be generated on the 1712 receipt of an Error Indication packet, however. Note that one 1713 possible authentication failure is the lack of an Authentication 1714 Extension; the presence or absence of the Authentication Extension 1715 is a local matter. 1717 0 1 2 3 1718 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 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Authentication Type | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | | 1723 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1724 | | 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 The Authentication Type field identifies the authentication method in 1728 use. Currently assigned values are: 1730 1 - Cleartext Password 1731 2 - Keyed MD5 1733 All other values are reserved. 1735 The Authentication Data field contains the type-specific 1736 authentication information. 1738 In the case of Cleartext Password Authentication, the Authentication 1739 Data consists of a variable length password. 1741 In the case of Keyed MD5 Authentication, the Authentication Data 1742 contains the 16 byte MD5 digest of the entire NHRP packet, including 1743 the encapsulated protocol's header, with the authentication key 1744 appended to the end of the packet. The authentication key is not 1745 transmitted with the packet. 1747 Distribution of authentication keys is outside the scope of this 1748 document. 1750 5.3.8 NHRP Vendor-Private Extension 1752 Compulsory = 0 1753 Type = 8 1754 Length = variable 1756 The NHRP Vendor-Private Extension is carried in NHRP packets to 1757 convey vendor-private information or NHRP extensions between NHRP 1758 speakers. This extension may be used at any time; if the receiver 1759 does not handle this extension, or does not match the vendor ID in 1760 the extension, then the extension may be completely ignored by the 1761 receiver. The first 24 bits of the extension's payload (following 1762 the length field) contains the 802 vendor ID as assigned by the IEEE 1763 [6]. The remaining octets in the payload are vendor-dependent. 1765 5.3.9 Additional Next Hop Entries Extension 1767 Compulsory = 0 1768 Type = 9 1769 Length = variable 1771 This extension may be used to return multiple Next Hop entries in a 1772 single NHRP Reply packet. This extension MUST only be used for 1773 positive replies. The preference values are used to specify the 1774 relative preference of the entries contained in the extension. The 1775 same next Hop Protocol address may be associated with multiple NBMA 1776 addresses. Load-splitting may be performed over the addresses, given 1777 equal preference values, and the alternative addresses may be used in 1778 case of connectivity failure in the NBMA subnetwork (such as a failed 1779 call attempt in connection-oriented NBMA subnetworks). 1781 0 1 2 3 1782 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 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Unused | Proto Length | Next Hop Holding Time | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | NH Addr T/L | NH SAddr T/L | Preference | unused | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Next Hop Protocol Address (variable length) | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Next Hop NBMA Address (variable length) | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | Next Hop NBMA Subaddress (variable length) | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 ..................... 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Unused | Proto Length | Next Hop Holding Time | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | NH Addr T/L | NH SAddr T/L | Preference | unused | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Next Hop Protocol Address (variable length) | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Next Hop NBMA Address (variable length) | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Next Hop NBMA Subaddress (variable length) | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 An NHS is not allowed to reply to an NHRP request for authoritative 1808 information with cached information, but may do so for an NHRP 1809 Request which indicates a request for non-authoritative information. 1810 An NHS may reply to an NHRP request for non-authoritative information 1811 with authoritative information. 1813 Proto Length 1814 The length in octets, of the internetwork layer protocol addresses 1815 appearing in this packet. If this length is not a multiple of 4, 1816 each internetwork layer address is zero-filled to the nearest 32- 1817 bit boundary. 1819 Next Hop Holding Time 1820 The Next Hop Address Holding Time field specifies the number of 1821 seconds for which the next hop NBMA information is considered to be 1822 valid. Cached information SHALL be discarded when the holding time 1823 expires. Must be set to 0 on a NAK. 1825 NH Addr T/L 1826 Type & length of next hop NBMA address interpreted in the context 1827 of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 1828 ar$afn=0x0003 for ATM). When the address length is specified as 0 1829 no storage is allocated for the address. Set to 0 on a NAK. 1831 NH SAddr T/L 1832 Type & length of next hop NBMA subaddress interpreted in the 1833 context of the 'hardware' (NBMA media) indicated by ar$afn (e.g., 1834 ar$afn=0x0003 for ATM). When an NBMA technology has no concept of 1835 a subaddress the subaddress is always null with a length of 0. 1836 When the address length is specified as 0 no storage is allocated 1837 for the address. Set to 0 on a NAK. 1839 Preference 1840 This field specifies the preference of the Next Hop entry, relative 1841 to other Next Hop entries in this NHRP Reply packet which may be in 1842 the Additional Next Hop Entries Extension for the given 1843 internetworking protocol. Higher values indicate more preferable 1844 Next Hop entries. Action taken when multiple next hop entries have 1845 the highest preference value is a local matter. Set to 0 on a NAK. 1847 Next Hop Protocol Address 1848 This internetworkin layer address specifies the next hop. This 1849 will be the address of the destination host if it is directly 1850 attached to the NBMA subnetwork, or the egress router if it is not 1851 directly attached. 1853 Next Hop NBMA Address 1854 This is the NBMA address of the station that is the next hop for 1855 packets bound for the internetworking layer address specified. The 1856 NBMA address field itself is zero-filled to the nearest 32-bit 1857 boundary. 1859 Next Hop NBMA SubAddress 1860 This is the NBMA sub address of the station that is the next hop 1861 for packets bound for the internetworking layer address specified. 1862 The NBMA subaddress field itself is zero-filled to the nearest 32- 1863 bit boundary. 1865 6. Protocol Operation 1867 In this section, we discuss certain operational considerations of 1868 NHRP. 1870 6.1 Router-to-Router Operation 1872 In practice, the initiating and responding stations may be either 1873 hosts or routers. However, there is a possibility under certain 1874 conditions that a stable routing loop may occur if NHRP is used 1875 between two routers. In particular, attempting to establish an NHRP 1876 path across a boundary where information used in route selection is 1877 lost may result in a routing loop. Such situations include the loss 1878 of BGP path vector information, the interworking of multiple routing 1879 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 1880 circumstances, NHRP should not be used. This situation can be 1881 avoided if there are no "back door" paths between the entry and 1882 egress router outside of the NBMA subnetwork. Protocol mechanisms to 1883 relax these restrictions are under investigation. 1885 In general it is preferable to use mechanisms, if they exist, in 1886 routing protocols to resolve the egress point when the destination 1887 lies outside of the NBMA subnetwork, since such mechanisms will be 1888 more tightly coupled to the state of the routing system and will 1889 probably be less likely to create loops. 1891 6.2 Cache Management Issues 1893 The management of NHRP caches in the source station, the NHS serving 1894 the destination, and any intermediate NHSs is dependent on a number 1895 of factors. 1897 6.2.1 Cacheing Requirements 1899 Source Stations 1901 Source stations MUST cache all received replies that they are 1902 actively using. They also must cache "incomplete" entries, i.e., 1903 those for which a request has been sent but which a reply has not 1904 been received. This is necessary in order to preserve the Request 1905 ID for retries, and provides the state necessary to avoid 1906 triggering requests for every data packet sent to the destination. 1908 Source stations MUST purge expired information from their caches. 1909 Source stations MUST purge the appropriate cached information upon 1910 receipt of an NHRP Purge request packet. 1912 Source stations that are also NHSs may return cached information 1913 learned in response to its own Next Hop Resolution Request packets 1914 in reply to requests it receives, within the rules for Transit NHSs 1915 below. 1917 Serving NHSs 1919 The NHS serving the destination (the one which responds 1920 authoritatively to Next Hop Resolution Requests) SHOULD cache 1921 information about all requests to which it has responded if the 1922 information in the reply has the possibility of changing during its 1923 lifetime (so that an NHRP Purge request packet can be sent). The 1924 NBMA information provided by the source station in the Next Hop 1925 Resolution Request may be cached for the duration of its holding 1926 time. This information is considered to be stable, since it 1927 identifies a station directly attached to the NBMA subnetwork. An 1928 example of unstable information is NBMA information derived from a 1929 routing table, where that routing table information has not been 1930 guaranteed to be stable through administrative means. 1932 Transit NHSs 1934 A Transit NHS (lying along the NHRP path between the source station 1935 and the responding NHS) may cache information contained in Next Hop 1936 Resolution Request packets that it forwards. A Transit NHS may 1937 cache information contained in NHRP Reply packets that it forwards 1938 only if that reply has the Stable (B) bit set. It MUST discard any 1939 cached information whose holding time has expired. It may return 1940 cached information in response to non-authoritative requests only. 1942 6.2.2 Dynamics of Cached Information 1944 NBMA-Connected Destinations 1946 NHRP's most basic function is that of simple NBMA address 1947 resolution of stations directly attached to the NBMA subnetwork. 1948 These mappings are typically very static, and appropriately chosen 1949 holding times will minimize problems in the event that the NBMA 1950 address of a station must be changed. Stale information will cause 1951 a loss of connectivity, which may be used to trigger an 1952 authoritative Next Hop Resolution Request and bypass the old data. 1953 In the worst case, connectivity will fail until the cache entry 1954 times out. 1956 This applies equally to information marked in replies as being 1957 "stable" (via the "B" bit). 1959 This also applies equally well to source stations that are routers 1960 as well as those which are hosts. 1962 Note that the information carried in the Next Hop Resolution 1963 Request packet is always considered "stable" because it represents 1964 a station that is directly connected to the NBMA subnetwork. 1966 Destinations Off of the NBMA Subnetwork 1968 If the source of a request is a host and the destination is not 1969 directly attached to the NBMA subnetwork, and the route to that 1970 destination is not considered to be "stable," the destination 1971 mapping may be very dynamic (except in the case of a subnetwork 1972 where each destination is only singly homed to the NBMA 1973 subnetwork). As such the cached information may very likely become 1974 stale. The consequence of stale information in this case will be a 1975 suboptimal path (unless the internetwork has partitioned or some 1976 other routing failure has occurred). 1978 Strategies for maintaining NHRP cache information in the presence 1979 of dynamic routing changes will be discussed in a separate 1980 document. 1982 6.3 Use of the Destination Prefix Extension 1984 A certain amount of care needs to be taken when using the Destination 1985 Prefix Extension, in particular with regard to the prefix length 1986 advertised (and thus the size of the equivalence class specified by 1987 it). Assuming that the routers on the NBMA subnetwork are exchanging 1988 routing information, it should not be possible for an NHS to create a 1989 black hole by advertising too large of a set of destinations, but 1990 suboptimal routing (e.g., extra internetwork layer hops through the 1991 NBMA) can result. To avoid this situation an NHS that wants to send 1992 the Destination Prefix Extension MUST obey the following rule: 1994 The NHS examines the Network Layer Reachability Information (NLRI) 1995 associated with the route that the NHS would use to forward towards 1996 the destination (as specified by the Destination IP address in the 1997 Next Hop Resolution Request), and extracts from this NLRI the 1998 shortest address prefix such that: (a) the Destination IP address 1999 (from the Next Hop Resolution Request) is covered by the prefix, 2000 (b) the NHS does not have any routes with NLRI that forms a subset 2001 of what is covered by the prefix. The prefix may then be used for 2002 the Destination Prefix Extension. 2004 The NHRP Destination Prefix Extension should be used with restraint, 2005 in order to avoid NHRP stations choosing suboptimal transit paths 2006 when overlapping prefixes are available. This extension SHOULD only 2007 be used in an NHRP Reply when either: 2009 (a) All destinations covered by the prefix are on the NBMA network, or 2010 (b) All destinations covered by the prefix are directly attached to 2011 the NHRP responding station. 2013 For other cases, there may be no single optimal transit path for 2014 destinations encompassed by the address prefix, and an NHRP station 2015 may fail to choose the optimal transit path simply because it is not 2016 aware of all such paths. So for cases not covered by (a) and (b), an 2017 NHRP Reply packet should not include the NHRP Destination Prefix 2018 Extension. 2020 6.4 Domino Effect 2022 One could easy imagine a situation where a router, acting as an 2023 ingress station to the NBMA subnetwork, receives a data packet, such 2024 that this packet triggers an Next Hop Resolution Request. If the 2025 router forwards this data packet without waiting for an NHRP transit 2026 path to be established, then when the next router along the path 2027 receives the packet, the next router may do exactly the same - 2028 originate its own Next Hop Resolution Request (as well as forward the 2029 packet). In fact such a data packet may trigger Next Hop Resolution 2030 Request generation at every router along the path through an NBMA 2031 subnetwork. We refer to this phenomena as the NHRP "domino" effect. 2033 The NHRP domino effect is clearly undesirable. At best it may result 2034 in excessive NHRP traffic. At worst it may result in an excessive 2035 number of virtual circuits being established unnecessarily. 2036 Therefore, it is important to take certain measures to avoid or 2037 suppress this behavior. NHRP implementations for NHSs MUST provide a 2038 mechanism to address this problem. It is recommended that 2039 implementations provide one or more of the following solutions. 2041 Possibly the most straightforward solution for suppressing the domino 2042 effect would be to require transit routers to be preconfigured not to 2043 originate Next Hop Resolution Requests for data traffic which is 2044 simply being forwarded (not originated). In this case the routers 2045 avoid the domino effect through an administrative policy. 2047 A second possible solution would be to require that when a router 2048 forwards an Next Hop Resolution Request, the router instantiates a 2049 (short-lived) state. This state consists of the route that was used 2050 to forward the request. If the router receives a data packet, and 2051 the packet triggers an Next Hop Resolution Request generation by the 2052 router, the router checks whether the route to forward the request 2053 was recently used to forward some other Next Hop Resolution Request. 2054 If so, then the router suppresses generation of the new request (but 2055 still forwards the data packet). This solution also requires that 2056 when a station attempts to originate an Next Hop Resolution Request 2057 the station should send the Next Hop Resolution Request before the 2058 data packet that triggered the origination of the request. 2059 Otherwise, unnecessary Next Hop Resolution Requests may still be 2060 generated. 2062 A third possible strategy would be to configure a router in such a 2063 way that Next Hop Resolution Request generation by the router would 2064 be driven only by the traffic the router receives over its non-NBMA 2065 interfaces (interfaces that are not attached to an NBMA subnetwork). 2066 Traffic received by the router over its NBMA-attached interfaces 2067 would not trigger NHRP Next Hop Resolution Requests. Just as in the 2068 first case, such a router avoids the NHRP domino effect through 2069 administrative means. 2071 Lastly, rate limiting of Next Hop Resolution Requests may help to 2072 avoid the NHRP domino effect. Intermediate routers which would 2073 otherwise generate unnecessary Next Hop Resolution Requests may 2074 instead suppress such requests due to the measured request rate 2075 exceeding a certain threshold. Of course, such rate limiting would 2076 have to be very aggressive in order to completely avoid the domino 2077 effect. Further work is needed to analyze this solution. 2079 7. Security Considerations 2081 As in any routing protocol, there are a number of potential security 2082 attacks possible. Plausible examples include denial-of-service 2083 attacks, and masquerade attacks using register and purge packets. 2084 The use of authentication on all packets is recommended to avoid such 2085 attacks. 2087 The authentication schemes described in this document are intended to 2088 allow the receiver of a packet to validate the identity of the 2089 sender; they do not provide privacy or protection against replay 2090 attacks. 2092 Detailed security analysis of this protocol is for further study. 2094 8. Discussion 2096 The result of an Next Hop Resolution Request depends on how routing 2097 is configured among the NHSs of an NBMA subnetwork. If the 2098 destination station is directly connected to the NBMA subnetwork and 2099 the the routed path to it lies entirely within the NBMA subnetwork, 2100 the NHRP replies always return the NBMA address of the destination 2101 station itself rather than the NBMA address of some egress router. 2102 On the other hand, if the routed path exits the NBMA subnetwork, NHRP 2103 will be unable to resolve the NBMA address of the destination, but 2104 rather will return the address of the egress router. For 2105 destinations outside the NBMA subnetwork, egress routers and routers 2106 in the other subnetworks should exchange routing information so that 2107 the optimal egress router may be found. 2109 In addition to NHSs, an NBMA station could also be associated with 2110 one or more regular routers that could act as "connectionless 2111 servers" for the station. The station could then choose to resolve 2112 the NBMA next hop or just send the IP packets to one of its 2113 connectionless servers. The latter option may be desirable if 2114 communication with the destination is short-lived and/or doesn't 2115 require much network resources. The connectionless servers could, of 2116 course, be physically integrated in the NHSs by augmenting them with 2117 IP switching functionality. 2119 References 2121 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 2122 Govindan, draft-ietf-rolc-nbma-arp-00.txt. 2124 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 2126 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 2128 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 2129 and D. Piscitello, RFC 1209. 2131 [5] Protocol Identification in the Network Layer, ISO/IEC TR 2132 9577:1990. 2134 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 2136 [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, 2137 RFC1483. 2139 [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, 2140 A. Malis, D. Robinson, and R. Ullmann, RFC1356. 2142 [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and 2143 A. Malis, RFC1490. 2145 Acknowledgments 2147 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 2148 Govidan of ISI for their work on NBMA ARP and the original NHRP 2149 draft, which served as the basis for this work. John Burnett of 2150 Adaptive, Dennis Ferguson of ANS, Joel Halpern of Newbridge, Paul 2151 Francis of NTT, Tony Li and Yakov Rekhter of cisco, and Grenville 2152 Armitage of Bellcore should also be acknowledged for comments and 2153 suggestions that improved this work substantially. We would also 2154 like to thank the members of the Routing Over Large Clouds working 2155 group of the IETF, whose review and discussion of this document have 2156 been invaluable. 2158 Authors' Addresses 2160 Dave Katz David Piscitello 2161 cisco Systems Core Competence 2162 170 W. Tasman Dr. 1620 Tuckerstown Road 2163 San Jose, CA 95134 USA Dresher, PA 19025 USA 2165 Phone: +1 408 526 8284 Phone: +1 215 830 0692 2166 Email: dkatz@cisco.com Email: dave@corecom.com 2168 Bruce Cole James V. Luciani 2169 cisco Systems Ascom Nexion 2170 170 W. Tasman Dr. 289 Great Road 2171 San Jose, CA 95134 USA Acton, MA 01720-4379 USA 2173 Phone: +1 408 526 4000 Phone: +1 508 266 3450 2174 Email: bcole@cisco.com Email: luciani@nexen.com