idnits 2.17.1 draft-ietf-rolc-nhrp-13.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([13], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 966 has weird spacing: '... wishes to r...' == Line 1938 has weird spacing: '...a field is de...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An NHS MUST NOT change the order of extensions. That is, the order of extensions placed in an NHRP packet by an NHC (or by an NHS when an NHS sources a packet) MUST be preserved as the packet moves between NHSs. Minimal NHC implementations MUST only recognize, but not necessarily parse, the Vendor Private extension and the End Of Extensions extension. Extensions are only present in a "reply" if they were present in the corresponding "request" with the exception of Vendor Private extensions. The previous statement is not intended to preclude the creation of NHS-only extensions which might be added to and removed from NHRP packets by the same NHS; such extensions MUST not be propagated to NHCs. -- The 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 (June 1998) is 9439 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 534 -- Looks like a reference, but probably isn't: '0x00-00-5E' on line 534 -- Looks like a reference, but probably isn't: '0x00-03' on line 534 == Unused Reference: '2' is defined on line 2261, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2268, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1735 (ref. '1') ** Obsolete normative reference: RFC 1577 (ref. '3') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1483 (ref. '7') (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1490 (ref. '9') (Obsoleted by RFC 2427) ** Downref: Normative reference to an Informational RFC: RFC 1937 (ref. '10') ** Obsolete normative reference: RFC 2021 (ref. '11') (Obsoleted by RFC 4502) == Outdated reference: A later version (-04) exists of draft-ietf-ion-scsp-02 -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '16') Summary: 18 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing over Large Clouds Working Group James V. Luciani 3 INTERNET-DRAFT (Bay Networks) 4 Dave Katz 5 (cisco Systems) 6 David Piscitello 7 (Core Competence, Inc.) 8 Bruce Cole 9 (Juniper Networks) 10 Expires June 1998 12 NBMA Next Hop Resolution Protocol (NHRP) 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 33 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 34 document, are to be interpreted as described in [15]. 36 Abstract 38 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 39 NHRP can be used by a source station (host or router) connected to a 40 Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the 41 internetworking layer address and NBMA subnetwork addresses of the 42 "NBMA next hop" towards a destination station. If the destination is 43 connected to the NBMA subnetwork, then the NBMA next hop is the 44 destination station itself. Otherwise, the NBMA next hop is the 45 egress router from the NBMA subnetwork that is "nearest" to the 46 destination station. NHRP is intended for use in a multiprotocol 47 internetworking layer environment over NBMA subnetworks. 49 Note that while this protocol was developed for use with NBMA 50 subnetworks, it is possible, if not likely, that it will be applied 51 to BMA subnetworks as well. However, this usage of NHRP is for 52 further study. 54 This document is intended to be a functional superset of the NBMA 55 Address Resolution Protocol (NARP) documented in [1]. 57 Operation of NHRP as a means of establishing a transit path across an 58 NBMA subnetwork between two routers will be addressed in a separate 59 document (see [13]). 61 1. Introduction 63 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 64 (a host or router), wishing to communicate over a Non-Broadcast, 65 Multi-Access (NBMA) subnetwork, to determine the internetworking 66 layer addresses and NBMA addresses of suitable "NBMA next hops" 67 toward a destination station. A subnetwork can be non-broadcast 68 either because it technically doesn't support broadcasting (e.g., an 69 X.25 subnetwork) or because broadcasting is not feasible for one 70 reason or another (e.g., an SMDS multicast group or an extended 71 Ethernet would be too large). If the destination is connected to the 72 NBMA subnetwork, then the NBMA next hop is the destination station 73 itself. Otherwise, the NBMA next hop is the egress router from the 74 NBMA subnetwork that is "nearest" to the destination station. 76 One way to model an NBMA network is by using the notion of logically 77 independent IP subnets (LISs). LISs, as defined in [3] and [4], have 78 the following properties: 80 1) All members of a LIS have the same IP network/subnet number 81 and address mask. 83 2) All members of a LIS are directly connected to the same 84 NBMA subnetwork. 86 3) All hosts and routers outside of the LIS are accessed via a router. 88 4) All members of a LIS access each other directly (without routers). 90 Address resolution as described in [3] and [4] only resolves the next 91 hop address if the destination station is a member of the same LIS as 92 the source station; otherwise, the source station must forward 93 packets to a router that is a member of multiple LIS's. In multi-LIS 94 configurations, hop-by-hop address resolution may not be sufficient 95 to resolve the "NBMA next hop" toward the destination station, and IP 96 packets may have multiple IP hops through the NBMA subnetwork. 98 Another way to model NBMA is by using the notion of Local Address 99 Groups (LAGs) [10]. The essential difference between the LIS and the 100 LAG models is that while with the LIS model the outcome of the 101 "local/remote" forwarding decision is driven purely by addressing 102 information, with the LAG model the outcome of this decision is 103 decoupled from the addressing information and is coupled with the 104 Quality of Service and/or traffic characteristics. With the LAG 105 model any two entities on a common NBMA network could establish a 106 direct communication with each other, irrespective of the entities' 107 addresses. 109 Support for the LAG model assumes the existence of a mechanism that 110 allows any entity (i.e., host or router) connected to an NBMA network 111 to resolve an internetworking layer address to an NBMA address for 112 any other entity connected to the same NBMA network. This resolution 113 would take place regardless of the address assignments to these 114 entities. Within the parameters described in this document, NHRP 115 describes such a mechanism. For example, when the internetworking 116 layer address is of type IP, once the NBMA next hop has been 117 resolved, the source may either start sending IP packets to the 118 destination (in a connectionless NBMA subnetwork such as SMDS) or may 119 first establish a connection to the destination with the desired 120 bandwidth (in a connection-oriented NBMA subnetwork such as ATM). 122 Use of NHRP may be sufficient for hosts doing address resolution when 123 those hosts are directly connected to an NBMA subnetwork, allowing 124 for straightforward implementations in NBMA stations. NHRP also has 125 the capability of determining the egress point from an NBMA 126 subnetwork when the destination is not directly connected to the NBMA 127 subnetwork and the identity of the egress router is not learned by 128 other methods (such as routing protocols). Optional extensions to 129 NHRP provide additional robustness and diagnosability. 131 Address resolution techniques such as those described in [3] and [4] 132 may be in use when NHRP is deployed. ARP servers and services over 133 NBMA subnetworks may be required to support hosts that are not 134 capable of dealing with any model for communication other than the 135 LIS model, and deployed hosts may not implement NHRP but may continue 136 to support ARP variants such as those described in [3] and [4]. NHRP 137 is intended to reduce or eliminate the extra router hops required by 138 the LIS model, and can be deployed in a non-interfering manner with 139 existing ARP services [14]. 141 The operation of NHRP to establish transit paths across NBMA 142 subnetworks between two routers requires additional mechanisms to 143 avoid stable routing loops, and will be described in a separate 144 document (see [13]). 146 2. Overview 148 2.1 Terminology 150 The term "network" is highly overloaded, and is especially confusing 151 in the context of NHRP. We use the following terms: 153 Internetwork layer--the media-independent layer (IP in the case of 154 TCP/IP networks). 156 Subnetwork layer--the media-dependent layer underlying the 157 internetwork layer, including the NBMA technology (ATM, X.25, SMDS, 158 etc.) 160 The term "server", unless explicitly stated to the contrary, refers 161 to a Next Hop Server (NHS). An NHS is an entity performing the 162 Next Hop Resolution Protocol service within the NBMA cloud. An NHS 163 is always tightly coupled with a routing entity (router, route 164 server or edge device) although the converse is not yet guaranteed 165 until ubiquitous deployment of this functionality occurs. Note 166 that the presence of intermediate routers that are not coupled with 167 an NHS entity may preclude the use of NHRP when source and 168 destination stations on different sides of such routers and thus 169 such routers may partition NHRP reachability within an NBMA 170 network. 172 The term "client", unless explicitly stated to the contrary, refers 173 to a Next Hop Resolution Protocol client (NHC). An NHC is an 174 entity which initiates NHRP requests of various types in order to 175 obtain access to the NHRP service. 177 The term "station" generally refers to a host or router which 178 contains an NHRP entity. Occasionally, the term station will 179 describe a "user" of the NHRP client or service functionality; the 180 difference in usage is largely semantic. 182 2.2 Protocol Overview 184 In this section, we briefly describe how a source S (which 185 potentially can be either a router or a host) uses NHRP to determine 186 the "NBMA next hop" to destination D. 188 For administrative and policy reasons, a physical NBMA subnetwork may 189 be partitioned into several, disjoint "Logical NBMA subnetworks". A 190 Logical NBMA subnetwork is defined as a collection of hosts and 191 routers that share unfiltered subnetwork connectivity over an NBMA 192 subnetwork. "Unfiltered subnetwork connectivity" refers to the 193 absence of closed user groups, address screening or similar features 194 that may be used to prevent direct communication between stations 195 connected to the same NBMA subnetwork. (Hereafter, unless otherwise 196 specified, we use the term "NBMA subnetwork" to mean *logical* NBMA 197 subnetwork.) 199 Placed within the NBMA subnetwork are one or more entities that 200 implement the NHRP protocol. Such stations which are capable of 201 answering NHRP Resolution Requests are known as "Next Hop Servers" 202 (NHSs). Each NHS serves a set of destination hosts, which may or may 203 not be directly connected to the NBMA subnetwork. NHSs cooperatively 204 resolve the NBMA next hop within their logical NBMA subnetwork. In 205 addition to NHRP, NHSs may support "classical" ARP service; however, 206 this will be the subject of a separate document [14]. 208 An NHS maintains a cache which contains protocol layer address to 209 NBMA subnetwork layer address resolution information. This cache can 210 be constructed from information obtained from NHRP Register packets 211 (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply 212 packets, or through mechanisms outside the scope of this document 213 (examples of such mechanisms might include ARP[3] and pre-configured 214 tables). Section 6.2 further describes cache management issues. 216 For a station within a given LIS to avoid providing NHS 217 functionality, there must be one or more NHSs within the NBMA 218 subnetwork which are providing authoritative address resolution 219 information on its behalf. Such an NHS is said to be "serving" the 220 station. A station on a LIS that lacks NHS functionality and is a 221 client of the NHRP service is known as NHRP Client or just NHCs. If 222 a serving NHS is to be able to supply the address resolution 223 information for an NHC then NHSs must exist at each hop along all 224 routed paths between the NHC making the resolution request and the 225 destination NHC. The last NHRP entity along the routed path is the 226 serving NHS; that is, NHRP Resolution Requests are not forwarded to 227 destination NHCs but rather are processed by the serving NHS. 229 An NHC also maintains a cache of protocol address to NBMA address 230 resolution information. This cache is populated through information 231 obtained from NHRP Resolution Reply packets, from manual 232 configuration, or through mechanisms outside the scope of this 233 document. 235 The protocol proceeds as follows. An event occurs triggering station 236 S to want to resolve the NBMA address of a path to D. This is most 237 likely to be when a data packet addressed to station D is to be 238 emitted from station S (either because station S is a host, or 239 station S is a transit router), but the address resolution could also 240 be triggered by other means (a routing protocol update packet, for 241 example). Station S first determines the next hop to station D 242 through normal routing processes (for a host, the next hop may simply 243 be the default router; for routers, this is the "next hop" to the 244 destination internetwork layer address). If the destination's 245 address resolution information is already available in S's cache then 246 that information is used to forward the packet. Otherwise, if the 247 next hop is reachable through one of its NBMA interfaces, S 248 constructs an NHRP Resolution Request packet (see Section 5.2.1) 249 containing station D's internetwork layer address as the (target) 250 destination address, S's own internetwork layer address as the source 251 address (Next Hop Resolution Request initiator), and station S's NBMA 252 addressing information. Station S may also indicate that it prefers 253 an authoritative NHRP Resolution Reply (i.e., station S only wishes 254 to receive an NHRP Resolution Reply from an NHS serving the 255 destination NHC). Station S emits the NHRP Resolution Request packet 256 towards the destination. 258 If the NHRP Resolution Request is triggered by a data packet then S 259 may, while awaiting an NHRP Resolution Reply, choose to dispose of 260 the data packet in one of the following ways: 262 (a) Drop the packet 263 (b) Retain the packet until the NHRP Resolution Reply arrives 264 and a more optimal path is available 265 (c) Forward the packet along the routed path toward D 267 The choice of which of the above to perform is a local policy matter, 268 though option (c) is the recommended default, since it may allow data 269 to flow to the destination while the NBMA address is being resolved. 270 Note that an NHRP Resolution Request for a given destination MUST NOT 271 be triggered on every packet. 273 When the NHS receives an NHRP Resolution Request, a check is made to 274 see if it serves station D. If the NHS does not serve D, the NHS 275 forwards the NHRP Resolution Request to another NHS. Mechanisms for 276 determining how to forward the NHRP Resolution Request are discussed 277 in Section 3. 279 If this NHS serves D, the NHS resolves station D's NBMA address 280 information, and generates a positive NHRP Resolution Reply on D's 281 behalf. NHRP Resolution Replies in this scenario are always marked 282 as "authoritative". The NHRP Resolution Reply packet contains the 283 address resolution information for station D which is to be sent back 284 to S. Note that if station D is not on the NBMA subnetwork, the next 285 hop internetwork layer address will be that of the egress router 286 through which packets for station D are forwarded. 288 A transit NHS receiving an NHRP Resolution Reply may cache the 289 address resolution information contained therein. To a subsequent 290 NHRP Resolution Request, this NHS may respond with the cached, "non- 291 authoritative" address resolution information if the NHS is permitted 292 to do so (see Sections 5.2.2 and 6.2 for more information on non- 293 authoritative versus authoritative NHRP Resolution Replies). Non- 294 authoritative NHRP Resolution Replies are distinguished from 295 authoritative NHRP Resolution Replies so that if a communication 296 attempt based on non-authoritative information fails, a source 297 station can choose to send an authoritative NHRP Resolution Request. 298 NHSs MUST NOT respond to authoritative NHRP Resolution Requests with 299 cached information. 301 If the determination is made that no NHS in the NBMA subnetwork can 302 reply to the NHRP Resolution Request for D then a negative NHRP 303 Resolution Reply (NAK) is returned. This occurs when (a) no next-hop 304 resolution information is available for station D from any NHS, or 305 (b) an NHS is unable to forward the NHRP Resolution Request (e.g., 306 connectivity is lost). 308 NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, 309 and NHRP Error Indications follow a routed path in the same fashion 310 that NHRP Resolution Requests and NHRP Resolution Replies do. 311 Specifically, "requests" and "indications" follow the routed path 312 from Source Protocol Address (which is the address of the station 313 initiating the communication) to the Destination Protocol Address. 314 "Replies", on the other hand, follow the routed path from the 315 Destination Protocol Address back to the Source Protocol Address with 316 the following exceptions: in the case of a NHRP Registration Reply 317 and in the case of an NHC initiated NHRP Purge Request, the packet is 318 always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if 319 one does not exists then one MUST be created. 321 NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA 322 subnetwork however further study is being done in this area (see 323 Section 7). Thus, the internetwork layer data traffic out of and 324 into an NBMA subnetwork always traverses an internetwork layer router 325 at its border. 327 NHRP optionally provides a mechanism to send a NHRP Resolution Reply 328 which contains aggregated address resolution information. For 329 example, suppose that router X is the next hop from station S to 330 station D and that X is an egress router for all stations sharing an 331 internetwork layer address prefix with station D. When an NHRP 332 Resolution Reply is generated in response to a NHRP Resolution 333 Request, the responder may augment the internetwork layer address of 334 station D with a prefix length (see Section 5.2.0.1). A subsequent 335 (non-authoritative) NHRP Resolution Request for some destination that 336 shares an internetwork layer address prefix (for the number of bits 337 specified in the prefix length) with D may be satisfied with this 338 cached information. See section 6.2 regarding caching issues. 340 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 341 (e.g., X.25 closed user group facility, or SMDS address screens), to 342 trace the routed path that an NHRP packet takes, or to provide loop 343 detection and diagnostic capabilities, a "Route Record" may be 344 included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route 345 Record extensions are the NHRP Forward Transit NHS Record Extension 346 and the NHRP Reverse Transit NHS Record Extension. They contain the 347 internetwork (and subnetwork layer) addresses of all intermediate 348 NHSs between source and destination and between destination and 349 source respectively. When a source station is unable to communicate 350 with the responder (e.g., an attempt to open an SVC fails), it may 351 attempt to do so successively with other subnetwork layer addresses 352 in the NHRP Forward Transit NHS Record Extension until it succeeds 353 (if authentication policy permits such action). This approach can 354 find a suitable egress point in the presence of subnetwork-layer 355 filtering (which may be source/destination sensitive, for instance, 356 without necessarily creating separate logical NBMA subnetworks) or 357 subnetwork-layer congestion (especially in connection-oriented 358 media). 360 3. Deployment 362 NHRP Resolution Requests traverse one or more hops within an NBMA 363 subnetwork before reaching the station that is expected to generate a 364 response. Each station, including the source station, chooses a 365 neighboring NHS to which it will forward the NHRP Resolution Request. 366 The NHS selection procedure typically involves applying a destination 367 protocol layer address to the protocol layer routing table which 368 causes a routing decision to be returned. This routing decision is 369 then used to forward the NHRP Resolution Request to the downstream 370 NHS. The destination protocol layer address previously mentioned is 371 carried within the NHRP Resolution Request packet. Note that even 372 though a protocol layer address was used to acquire a routing 373 decision, NHRP packets are not encapsulated within a protocol layer 374 header but rather are carried at the NBMA layer using the 375 encapsulation described in Section 5. 377 Each NHS/router examines the NHRP Resolution Request packet on its 378 way toward the destination. Each NHS which the NHRP packet traverses 379 on the way to the packet's destination might modify the packet (e.g., 380 updating the Forward Record extension). Ignoring error situations, 381 the NHRP Resolution Request eventually arrives at a station that is 382 to generate an NHRP Resolution Reply. This responding station 383 "serves" the destination. The responding station generates an NHRP 384 Resolution Reply using the source protocol address from within the 385 NHRP packet to determine where the NHRP Resolution Reply should be 386 sent. 388 Rather than use routing to determine the next hop for an NHRP packet, 389 an NHS may use other applicable means (such as static configuration 390 information ) in order to determine to which neighboring NHSs to 391 forward the NHRP Resolution Request packet as long as such other 392 means would not cause the NHRP packet to arrive at an NHS which is 393 not along the routed path. The use of static configuration 394 information for this purpose is beyond the scope of this document. 396 The NHS serving a particular destination must lie along the routed 397 path to that destination. In practice, this means that all egress 398 routers must double as NHSs serving the destinations beyond them, and 399 that hosts on the NBMA subnetwork are served by routers that double 400 as NHSs. Also, this implies that forwarding of NHRP packets within 401 an NBMA subnetwork requires a contiguous deployment of NHRP capable 402 routers. It is important that, in a given LIS/LAG which is using 403 NHRP, all NHSs within the LIS/LAG have at least some portion of their 404 resolution databases synchronized so that a packet arriving at one 405 router/NHS in a given LIS/LAG will be forwarded in the same fashion 406 as a packet arriving at a different router/NHS for the given LIS/LAG. 407 One method, among others, is to use the Server Cache Synchronization 408 Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used 409 when a LIS/LAG contains two or more router/NHSs. 411 During migration to NHRP, it cannot be expected that all routers 412 within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic 413 which would otherwise need to be forwarded through such routers can 414 be expected to be dropped due to the NHRP packet not being 415 recognized. In this case, NHRP will be unable to establish any 416 transit paths whose discovery requires the traversal of the non-NHRP 417 speaking routers. If the client has tried and failed to acquire a 418 cut through path then the client should use the network layer routed 419 path as a default. 421 If an NBMA technology offers a group, an anycast, or a multicast 422 addressing feature then the NHC may be configured with such an 423 address (appropriate to the routing realm it participates in) which 424 would be assigned to all NHS serving that routing realm. This 425 address can then be used for establishing an initial connection to an 426 NHS to transmit a registration request. This address may not be used 427 for sending NHRP requests. The resulting VC may be used for NHRP 428 requests if and only if the registration response is received over 429 that VC, thereby indicating that one happens to have anycast 430 connected to an NHS serving the LIS/LAG. In the case of non- 431 connection oriented networks, or of multicast (rather than anycast) 432 addresses, the addres MUST NOT be used for sending NHRP resolution 433 requests. 435 When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined 436 for the NHC directly to the NHC. That is, the NHRP message MUST NOT 437 transit through any NHS which is not serving the NHC when the NHRP 438 message is currently at an NHS which does serve the NHC (this, of 439 course, assumes the NHRP message is destined for the NHC). Further, 440 an NHS which serves an NHC SHOULD have a direct NBMA level connection 441 to that NHC (see Section 5.2.3 and 5.2.4 for examples). 443 With the exception of NHRP Registration Requests (see Section 5.2.3 444 and 5.2.4 for details of the NHRP Registration Request case), an NHC 445 MUST send NHRP messages over a direct NBMA level connection between 446 the serving NHS and the served NHC. 448 It may not be desirable to maintain semi-permanent NBMA level 449 connectivity between the NHC and the NHS. In this case, when NBMA 450 level connectivity is initially setup between the NHS and the NHC (as 451 described in Section 5.2.4), the NBMA address of the NHS should be 452 obtained through the NBMA level signaling technology. This address 453 should be stored for future use in setting up subsequent NBMA level 454 connections. A somewhat more information rich technique to obtain 455 the address information (and more) of the serving NHS would be for 456 the NHC to include the Responder Address extension (see Section 457 5.3.1) in the NHRP Registration Request and to store the information 458 returned to the NHC in the Responder Address extension which is 459 subsequently included in the NHRP Registration Reply. Note also 460 that, in practice, a client's default router should also be its NHS; 461 thus a client may be able to know the NBMA address of its NHS from 462 the configuration which was already required for the client to be 463 able to communicate. Further, as mentioned in Section 4, NHCs may be 464 configured with the addressing information of one or more NHSs. 466 4. Configuration 468 Next Hop Clients 470 An NHC connected to an NBMA subnetwork MAY be configured with the 471 Protocol address(es) and NBMA address(es) of its NHS(s). The 472 NHS(s) will likely also represent the NHC's default or peer 473 routers, so their NBMA addresses may be obtained from the NHC's 474 existing configuration. If the NHC is attached to several 475 subnetworks (including logical NBMA subnetworks), the NHC should 476 also be configured to receive routing information from its NHS(s) 477 and peer routers so that it can determine which internetwork layer 478 networks are reachable through which subnetworks. 480 Next Hop Servers 482 An NHS is configured with knowledge of its own internetwork layer 483 and NBMA addresses. An NHS MAY also be configured with a set of 484 internetwork layer address prefixes that correspond to the 485 internetwork layer addresses of the stations it serves. The NBMA 486 addresses of the stations served by the NHS may be learned via NHRP 487 Registration packets. 489 If a served NHC is attached to several subnetworks, the 490 router/route-server coresident with the serving NHS may also need 491 to be configured to advertise routing information to such NHCs. 493 If an NHS acts as an egress router for stations connected to other 494 subnetworks than the NBMA subnetwork, the NHS must, in addition to 495 the above, be configured to exchange routing information between 496 the NBMA subnetwork and these other subnetworks. 498 In all cases, routing information is exchanged using conventional 499 intra-domain and/or inter-domain routing protocols. 501 5. NHRP Packet Formats 503 This section describes the format of NHRP packets. In the following, 504 unless otherwise stated explicitly, the unqualified term "request" 505 refers generically to any of the NHRP packet types which are 506 "requests". Further, unless otherwise stated explicitly, the 507 unqualified term "reply" refers generically to any of the NHRP packet 508 types which are "replies". 510 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 511 Extensions Part. The Fixed Part is common to all NHRP packet types. 512 The Mandatory Part MUST be present, but varies depending on packet 513 type. The Extensions Part also varies depending on packet type, and 514 need not be present. 516 The length of the Fixed Part is fixed at 20 octets. The length of 517 the Mandatory Part is determined by the contents of the extensions 518 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 519 length is equal to total packet length (ar$pktsz) minus 20 otherwise 520 the mandatory part length is equal to ar$extoff minus 20. The length 521 of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs 522 may increase the size of an NHRP packet as a result of extension 523 processing, but not beyond the offered maximum packet size of the 524 NBMA network. 526 NHRP packets are actually members of a wider class of address mapping 527 and management protocols being developed by the IETF. A specific 528 encapsulation, based on the native formats used on the particular 529 NBMA network over which NHRP is carried, indicates the generic IETF 530 mapping and management protocol. For example, SMDS networks always 531 use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet 532 is preceded by the following LLC/SNAP encapsulation: 534 [0xAA-AA-03] [0x00-00-5E] [0x00-03] 536 The first three octets are LLC, indicating that SNAP follows. The 537 SNAP OUI portion is the IANA's OUI, and the SNAP PID portion 538 identifies the mapping and management protocol. A field in the Fixed 539 Header following the encapsulation indicates that it is NHRP. 541 ATM uses either LLC/SNAP encapsulation of each packet (including 542 NHRP), or uses no encapsulation on VCs dedicated to a single protocol 543 (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or 544 identification of NHRP, using a NLPID of 0x0080 and the same SNAP 545 contents as above (see [8], [9]). 547 Fields marked "unused" MUST be set to zero on transmission, and 548 ignored on receipt. 550 Most packet types (ar$op.type) have both internetwork layer 551 protocol-independent fields and protocol-specific fields. The 552 protocol type/snap fields (ar$pro.type/snap) qualify the format of 553 the protocol-specific fields. 555 5.1 NHRP Fixed Header 557 The Fixed Part of the NHRP packet contains those elements of the NHRP 558 packet which are always present and do not vary in size with the type 559 of packet. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | ar$afn | ar$pro.type | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | ar$pro.snap | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | ar$pro.snap | ar$hopcnt | ar$pktsz | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | ar$chksum | ar$extoff | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | ar$op.version | ar$op.type | ar$shtl | ar$sstl | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 ar$afn 576 Defines the type of "link layer" addresses being carried. This 577 number is taken from the 'address family number' list specified in 578 [6]. This field has implications to the coding of ar$shtl and 579 ar$sstl as described below. 581 ar$pro.type 582 field is a 16 bit unsigned integer representing the following 583 number space: 585 0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 586 0x0100 to 0x03FF Reserved for future use by the IETF. 587 0x0400 to 0x04FF Allocated for use by the ATM Forum. 588 0x0500 to 0x05FF Experimental/Local use. 589 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 591 (based on the observations that valid Ethertypes are never smaller 592 than 0x600, and NLPIDs never larger than 0xFF.) 594 ar$pro.snap 595 When ar$pro.type has a value of 0x0080, a SNAP encoded extension is 596 being used to encode the protocol type. This snap extension is 597 placed in the ar$pro.snap field. This is termed the 'long form' 598 protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be 599 zero on transmit and ignored on receive. The ar$pro.type field 600 itself identifies the protocol being referred to. This is termed 601 the 'short form' protocol ID. 603 In all cases, where a protocol has an assigned number in the 604 ar$pro.type space (excluding 0x0080) the short form MUST be used 605 when transmitting NHRP messages; i.e., if Ethertype or NLPID 606 codings exist then they are used on transmit rather than the 607 ethertype. If both Ethertype and NLPID codings exist then when 608 transmitting NHRP messages, the Ethertype coding MUST be used (this 609 is consistent with RFC 1483 coding). So, for example, the 610 following codings exist for IP: 612 SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00 613 NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00 614 Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00 616 and thus, since the Ethertype coding exists, it is used in 617 preference. 619 ar$hopcnt 620 The Hop count indicates the maximum number of NHSs that an NHRP 621 packet is allowed to traverse before being discarded. This field 622 is used in a similar fashion to the way that a TTL is used in an IP 623 packet and should be set accordingly. Each NHS decrements the TTL 624 as the NHRP packet transits the NHS on the way to the next hop 625 along the routed path to the destination. If an NHS receives an 626 NHRP packet which it would normally forward to a next hop and that 627 packet contains an ar$hopcnt set to zero then the NHS sends an 628 error indication message back to the source protocol address 629 stating that the hop count has been exceeded (see Section 5.2.7) 630 and the NHS drops the packet in error; however, an error 631 indication is never sent as a result of receiving an error 632 indication. When a responding NHS replies to an NHRP request, that 633 NHS places a value in ar$hopcnt as if it were sending a request of 634 its own. 636 ar$pktsz 637 The total length of the NHRP packet, in octets (excluding link 638 layer encapsulation). 640 ar$chksum 641 The standard IP checksum over the entire NHRP packet starting at 642 the fixed header. If the packet is an odd number of bytes in 643 length then this calculation is performed as if a byte set to 0x00 644 is appended to the end of the packet. 646 ar$extoff 647 This field identifies the existence and location of NHRP 648 extensions. If this field is 0 then no extensions exist otherwise 649 this field represents the offset from the beginning of the NHRP 650 packet (i.e., starting from the ar$afn field) of the first 651 extension. 653 ar$op.version 654 This field indicates what version of generic address mapping and 655 management protocol is represented by this message. 657 0 MARS protocol [11]. 658 1 NHRP as defined in this document. 659 0x02 - 0xEF Reserved for future use by the IETF. 660 0xF0 - 0xFE Allocated for use by the ATM Forum. 661 0xFF Experimental/Local use. 663 ar$op.type 664 When ar$op.version == 1, this is the NHRP packet type: NHRP 665 Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration 666 Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP 667 Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet 668 Types in the range 128 to 255 are reserved for research or use in 669 other protocol development and will be administered by IANA as 670 described in Section 9. 672 ar$shtl 673 Type & length of source NBMA address interpreted in the context of 674 the 'address family number'[6] indicated by ar$afn. See below for 675 more details. 677 ar$sstl 678 Type & length of source NBMA subaddress interpreted in the context 679 of the 'address family number'[6] indicated by ar$afn. When an 680 NBMA technology has no concept of a subaddress, the subaddress 681 length is always coded ar$sstl = 0 and no storage is allocated for 682 the subaddress in the appropriate mandatory part. See below for 683 more details. 685 Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr 686 T/L) and subnetwork layer subaddresses type/length fields (e.g., 687 ar$sstl, Cli SAddr T/L) are coded as follows: 689 7 6 5 4 3 2 1 0 690 +-+-+-+-+-+-+-+-+ 691 |0|x| length | 692 +-+-+-+-+-+-+-+-+ 694 The most significant bit is reserved and MUST be set to zero. The 695 second most significant bit (x) is a flag indicating whether the 696 address being referred to is in: 698 - NSAP format (x = 0). 699 - Native E.164 format (x = 1). 701 For NBMA technologies that use neither NSAP nor E.164 format 702 addresses, x = 0 SHALL be used to indicate the native form for the 703 particular NBMA technology. 705 If the NBMA network is ATM and a subaddress (e.g., Source NBMA 706 SubAddress, Client NBMA SubAddress) is to be included in any part of 707 the NHRP packet then ar$afn MUST be set to 0x000F; further, the 708 subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr 709 T/L) and subnetwork layer subaddress type/length fields (e.g., 710 ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA 711 network is ATM and no subaddress field is to be included in any part 712 of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 713 (E.164) accordingly. 715 The bottom 6 bits is an unsigned integer value indicating the length 716 of the associated NBMA address in octets. If this value is zero the 717 flag x is ignored. 719 5.2.0 Mandatory Part 721 The Mandatory Part of the NHRP packet contains the operation specific 722 information (e.g., NHRP Resolution Request/Reply, etc.) and variable 723 length data which is pertinent to the packet type. 725 5.2.0.1 Mandatory Part Format 727 Sections 5.2.1 through 5.2.6 have a very similar mandatory part. 728 This mandatory part includes a common header and zero or more Client 729 Information Entries (CIEs). Section 5.2.7 has a different format 730 which is specified in that section. 732 The common header looks like the following: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Src Proto Len | Dst Proto Len | Flags | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Request ID | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Source NBMA Address (variable length) | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Source NBMA Subaddress (variable length) | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Source Protocol Address (variable length) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Destination Protocol Address (variable length) | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 And the CIEs have the following format: 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Code | Prefix Length | unused | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Maximum Transmission Unit | Holding Time | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Client NBMA Address (variable length) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Client NBMA Subaddress (variable length) | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Client Protocol Address (variable length) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 ..................... 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Code | Prefix Length | unused | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Maximum Transmission Unit | Holding Time | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Client NBMA Address (variable length) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Client NBMA Subaddress (variable length) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Client Protocol Address (variable length) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 The meanings of the fields are as follows: 783 Src Proto Len 784 This field holds the length in octets of the Source Protocol 785 Address. 787 Dst Proto Len 788 This field holds the length in octets of the Destination Protocol 789 Address. 791 Flags 792 These flags are specific to the given message type and they are 793 explained in each section. 795 Request ID 796 A value which, when coupled with the address of the source, 797 provides a unique identifier for the information contained in a 798 "request" packet. This value is copied directly from an "request" 799 packet into the associated "reply". When a sender of a "request" 800 receives "reply", it will compare the Request ID and source address 801 information in the received "reply" against that found in its 802 outstanding "request" list. When a match is found then the 803 "request" is considered to be acknowledged. 805 The value is taken from a 32 bit counter that is incremented each 806 time a new "request" is transmitted. The same value MUST be used 807 when resending a "request", i.e., when a "reply" has not been 808 received for a "request" and a retry is sent after an appropriate 809 interval. 811 It is RECOMMENDED that the initial value for this number be 0. A 812 node MAY reuse a sequence number if and only if the reuse of the 813 sequence number is not precluded by use of a particular method of 814 synchronization (e.g., as described in Appendix A). 816 The NBMA address/subaddress form specified below allows combined 817 E.164/NSAPA form of NBMA addressing. For NBMA technologies without a 818 subaddress concept, the subaddress field is always ZERO length and 819 ar$sstl = 0. 821 Source NBMA Address 822 The Source NBMA address field is the address of the source station 823 which is sending the "request". If the field's length as specified 824 in ar$shtl is 0 then no storage is allocated for this address at 825 all. 827 Source NBMA SubAddress 828 The Source NBMA subaddress field is the address of the source 829 station which is sending the "request". If the field's length as 830 specified in ar$sstl is 0 then no storage is allocated for this 831 address at all. 833 For those NBMA technologies which have a notion of "Calling Party 834 Addresses", the Source NBMA Addresses above are the addresses used 835 when signaling for an SVC. 837 "Requests" and "indications" follow the routed path from Source 838 Protocol Address to the Destination Protocol Address. "Replies", on 839 the other hand, follow the routed path from the Destination Protocol 840 Address back to the Source Protocol Address with the following 841 exceptions: in the case of a NHRP Registration Reply and in the case 842 of an NHC initiated NHRP Purge Request, the packet is always returned 843 via a direct VC (see Sections 5.2.4 and 5.2.5). 845 Source Protocol Address 846 This is the protocol address of the station which is sending the 847 "request". This is also the protocol address of the station toward 848 which a "reply" packet is sent. 850 Destination Protocol Address 851 This is the protocol address of the station toward which a 852 "request" packet is sent. 854 Code 855 This field is message specific. See the relevant message sections 856 below. In general, this field is a NAK code; i.e., when the field 857 is 0 in a reply then the packet is acknowledging a request and if 858 it contains any other value the packet contains a negative 859 acknowledgment. 861 Prefix Length 862 This field is message specific. See the relevant message sections 863 below. In general, however, this fields is used to indicate that 864 the information carried in an NHRP message pertains to an 865 equivalence class of internetwork layer addresses rather than just 866 a single internetwork layer address specified. All internetwork 867 layer addresses that match the first "Prefix Length" bit positions 868 for the specific internetwork layer address are included in the 869 equivalence class. If this field is set to 0x00 then this field 870 MUST be ignored and no equivalence information is assumed (note 871 that 0x00 is thus equivalent to 0xFF). 873 Maximum Transmission Unit 874 This field gives the maximum transmission unit for the relevant 875 client station. If this value is 0 then either the default MTU is 876 used or the MTU negotiated via signaling is used if such 877 negotiation is possible for the given NBMA. 879 Holding Time 880 The Holding Time field specifies the number of seconds for which 881 the Next Hop NBMA information specified in the CIE is considered to 882 be valid. Cached information SHALL be discarded when the holding 883 time expires. This field must be set to 0 on a NAK. 885 Cli Addr T/L 886 Type & length of next hop NBMA address specified in the CIE. This 887 field is interpreted in the context of the 'address family 888 number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM). 890 Cli SAddr T/L 891 Type & length of next hop NBMA subaddress specified in the CIE. 893 This field is interpreted in the context of the 'address family 894 number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes 895 the address an E.164 and the subaddress an ATM Forum NSAP address). 896 When an NBMA technology has no concept of a subaddress, the 897 subaddress is always null with a length of 0. When the address 898 length is specified as 0 no storage is allocated for the address. 900 Cli Proto Len 901 This field holds the length in octets of the Client Protocol 902 Address specified in the CIE. 904 Preference 905 This field specifies the preference for use of the specific CIE 906 relative to other CIEs. Higher values indicate higher preference. 907 Action taken when multiple CIEs have equal or highest preference 908 value is a local matter. 910 Client NBMA Address 911 This is the client's NBMA address. 913 Client NBMA SubAddress 914 This is the client's NBMA subaddress. 916 Client Protocol Address 917 This is the client's internetworking layer address specified. 919 Note that an NHS may cache source address binding information from an 920 NHRP Resolution Request if and only if the conditions described in 921 Section 6.2 are met for the NHS. In all other cases, source address 922 binding information appearing in an NHRP message MUST NOT be cached. 924 5.2.1 NHRP Resolution Request 926 The NHRP Resolution Request packet has a Type code of 1. Its 927 mandatory part is coded as described in Section 5.2.0.1 and the 928 message specific meanings of the fields are as follows: 930 Flags - The flags field is coded as follows: 932 0 1 933 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 |Q|A|D|U|S| unused | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Q 939 Set if the station sending the NHRP Resolution Request is a 940 router; clear if the it is a host. 942 A 943 This bit is set in a NHRP Resolution Request if only 944 authoritative next hop information is desired and is clear 945 otherwise. See the NHRP Resolution Reply section below for 946 further details on the "A" bit and its usage. 948 D 949 Unused (clear on transmit) 951 U 952 This is the Uniqueness bit. This bit aids in duplicate address 953 detection. When this bit is set in an NHRP Resolution Request 954 and one or more entries exist in the NHS cache which meet the 955 requirements of the NHRP Resolution Request then only the CIE in 956 the NHS's cache with this bit set will be returned. Note that 957 even if this bit was set at registration time, there may still be 958 multiple CIEs that might fulfill the NHRP Resolution Request 959 because an entire subnet can be registered through use of the 960 Prefix Length in the CIE and the address of interest might be 961 within such a subnet. If the "uniqueness" bit is set and the 962 responding NHS has one or more cache entries which match the 963 request but no such cache entry has the "uniqueness" bit set, 964 then the NHRP Resolution Reply returns with a NAK code of "13 - 965 Binding Exists But Is Not Unique" and no CIE is included. If a 966 client wishes to receive non- unique Next Hop Entries, then 967 the client must have the "uniqueness" bit set to zero in its NHRP 968 Resolution Request. Note that when this bit is set in an NHRP 969 Registration Request, only a single CIE may be specified in the 970 NHRP Registration Request and that CIE must have the Prefix 971 Length field set to 0xFF. 973 S 974 Set if the binding between the Source Protocol Address and the 975 Source NBMA information in the NHRP Resolution Request is 976 guaranteed to be stable and accurate (e.g., these addresses are 977 those of an ingress router which is connected to an ethernet stub 978 network or the NHC is an NBMA attached host). 980 Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP 981 Resolution Request. If one is specified then that entry carries the 982 pertinent information for the client sourcing the NHRP Resolution 983 Request. Usage of the CIE in the NHRP Resolution Request is 984 described below: 986 Prefix Length 987 If a CIE is specified in the NHRP Resolution Request then the 988 Prefix Length field may be used to qualify the widest acceptable 989 prefix which may be used to satisfy the NHRP Resolution Request. 990 In the case of NHRP Resolution Request/Reply, the Prefix Length 991 specifies the equivalence class of addresses which match the 992 first "Prefix Length" bit positions of the Destination Protocol 993 Address. If the "U" bit is set in the common header then this 994 field MUST be set to 0xFF. 996 Maximum Transmission Unit 997 This field gives the maximum transmission unit for the source 998 station. A possible use of this field in the NHRP Resolution 999 Request packet is for the NHRP Resolution Requester to ask for a 1000 target MTU. 1002 Holding Time 1003 The Holding Time specified in the one CIE permitted to be 1004 included in an NHRP Resolution Request is the amount of time 1005 which the source address binding information in the NHRP 1006 Resolution Request is permitted to cached by transit and 1007 responding NHSs. Note that this field may only have a non-zero 1008 value if the S bit is set. 1010 All other fields in the CIE MUST be ignored and SHOULD be set to 0. 1012 The Destination Protocol Address in the common header of the 1013 Mandatory Part of this message contains the protocol address of the 1014 station for which resolution is desired. An NHC MUST send the NHRP 1015 Resolution Request directly to one of its serving NHSs (see Section 3 1016 for more information). 1018 5.2.2 NHRP Resolution Reply 1020 The NHRP Resolution Reply packet has a Type code of 2. CIEs 1021 correspond to Next Hop Entries in an NHS's cache which match the 1022 criteria in the NHRP Resolution Request. Its mandatory part is coded 1023 as described in Section 5.2.0.1. The message specific meanings of 1024 the fields are as follows: 1026 Flags - The flags field is coded as follows: 1028 0 1 1029 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 |Q|A|D|U|S| unused | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 Q 1035 Copied from the NHRP Resolution Request. Set if the NHRP 1036 Resolution Requester is a router; clear if it is a host. 1038 A 1039 Set if the next hop CIE in the NHRP Resolution Reply is 1040 authoritative; clear if the NHRP Resolution Reply is non- 1041 authoritative. 1043 When an NHS receives a NHRP Resolution Request for authoritative 1044 information for which it is the authoritative source, it MUST 1045 respond with a NHRP Resolution Reply containing all and only 1046 those next hop CIEs which are contained in the NHS's cache which 1047 both match the criteria of the NHRP Resolution Request and are 1048 authoritative cache entries. An NHS is an authoritative source 1049 for a NHRP Resolution Request if the information in the NHS's 1050 cache matches the NHRP Resolution Request criteria and that 1051 information was obtained through a NHRP Registration Request or 1052 through synchronization with an NHS which obtained this 1053 information through a NHRP Registration Request. An 1054 authoritative cache entry is one which is obtained through a NHRP 1055 Registration Request or through synchronization with an NHS which 1056 obtained this information through a NHRP Registration Request. 1058 An NHS obtains non-authoritative CIEs through promiscuous 1059 listening to NHRP packets other than NHRP Registrations which are 1060 directed at it. A NHRP Resolution Request which indicates a 1061 request for non-authoritative information should cause a NHRP 1062 Resolution Reply which contains all entries in the replying NHS's 1063 cache (i.e., both authoritative and non-authoritative) which 1064 match the criteria specified in the request. 1066 D 1067 Set if the association between destination and the associate next 1068 hop information included in all CIEs of the NHRP Resolution Reply 1069 is guaranteed to be stable for the lifetime of the information 1070 (the holding time). This is the case if the Next Hop protocol 1071 address in a CIE identifies the destination (though it may be 1072 different in value than the Destination address if the 1073 destination system has multiple addresses) or if the destination 1074 is not connected directly to the NBMA subnetwork but the egress 1075 router to that destination is guaranteed to be stable (such as 1076 when the destination is immediately adjacent to the egress router 1077 through a non-NBMA interface). 1079 U 1080 This is the Uniqueness bit. See the NHRP Resolution Request 1081 section above for details. When this bit is set, only one CIE is 1082 included since only one unique binding should exist in an NHS's 1083 cache. 1085 S 1086 Copied from NHRP Resolution Request message. 1088 One or more CIEs are specified in the NHRP Resolution Reply. Each CIE 1089 contains NHRP next hop information which the responding NHS has 1090 cached and which matches the parameters specified in the NHRP 1091 Resolution Request. If no match is found by the NHS issuing the NHRP 1092 Resolution Reply then a single CIE is enclosed with the a CIE Code 1093 set appropriately (see below) and all other fields MUST be ignored 1094 and SHOULD be set to 0. In order to facilitate the use of NHRP by 1095 minimal client implementations, the first CIE MUST contain the next 1096 hop with the highest preference value so that such an implementation 1097 need parse only a single CIE. 1099 Code 1100 If this field is set to zero then this packet contains a 1101 positively acknowledged NHRP Resolution Reply. If this field 1102 contains any other value then this message contains an NHRP 1103 Resolution Reply NAK which means that an appropriate 1104 internetworking layer to NBMA address binding was not available 1105 in the responding NHS's cache. If NHRP Resolution Reply contains 1106 a Client Information Entry with a NAK Code other than 0 then it 1107 MUST NOT contain any other CIE. Currently defined NAK Codes are 1108 as follows: 1110 4 - Administratively Prohibited 1112 An NHS may refuse an NHRP Resolution Request attempt for 1113 administrative reasons (due to policy constraints or routing 1114 state). If so, the NHS MUST send an NHRP Resolution Reply 1115 which contains a NAK code of 4. 1117 5 - Insufficient Resources 1119 If an NHS cannot serve a station due to a lack of resources 1120 (e.g., can't store sufficient information to send a purge if 1121 routing changes), the NHS MUST reply with a NAKed NHRP 1122 Resolution Reply which contains a NAK code of 5. 1124 12 - No Internetworking Layer Address to NBMA Address Binding 1125 Exists 1127 This code states that there were absolutely no internetworking 1128 layer address to NBMA address bindings found in the responding 1129 NHS's cache. 1131 13 - Binding Exists But Is Not Unique 1133 This code states that there were one or more internetworking 1134 layer address to NBMA address bindings found in the responding 1135 NHS's cache, however none of them had the uniqueness bit set. 1137 Prefix Length 1138 In the case of NHRP Resolution Reply, the Prefix Length specifies 1139 the equivalence class of addresses which match the first "Prefix 1140 Length" bit positions of the Destination Protocol Address. 1142 Holding Time 1143 The Holding Time specified in a CIE of an NHRP Resolution Reply 1144 is the amount of time remaining before the expiration of the 1145 client information which is cached at the replying NHS. It is 1146 not the value which was registered by the client. 1148 The remainder of the fields for the CIE for each next hop are 1149 filled out as they were defined when the next hop was registered 1150 with the responding NHS (or one of the responding NHS's 1151 synchronized servers) via the NHRP Registration Request. 1153 Load-splitting may be performed when more than one Client Information 1154 Entry is returned to a requester when equal preference values are 1155 specified. Also, the alternative addresses may be used in case of 1156 connectivity failure in the NBMA subnetwork (such as a failed call 1157 attempt in connection-oriented NBMA subnetworks). 1159 Any extensions present in the NHRP Resolution Request packet MUST be 1160 present in the NHRP Resolution Reply even if the extension is non- 1161 Compulsory. 1163 If an unsolicited NHRP Resolution Reply packet is received, an Error 1164 Indication of type Invalid NHRP Resolution Reply Received SHOULD be 1165 sent in response. 1167 When an NHS that serves a given NHC receives an NHRP Resolution Reply 1168 destined for that NHC then the NHS must MUST send the NHRP Resolution 1169 Reply directly to the NHC (see Section 3). 1171 5.2.3 NHRP Registration Request 1173 The NHRP Registration Request is sent from a station to an NHS to 1174 notify the NHS of the station's NBMA information. It has a Type code 1175 of 3. Each CIE corresponds to Next Hop information which is to be 1176 cached at an NHS. The mandatory part of an NHRP Registration Request 1177 is coded as described in Section 5.2.0.1. The message specific 1178 meanings of the fields are as follows: 1180 Flags - The flags field is coded as follows: 1182 0 1 1183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 |U| unused | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 U 1189 This is the Uniqueness bit. When set in an NHRP Registration 1190 Request, this bit indicates that the registration of the protocol 1191 address is unique within the confines of the set of synchronized 1192 NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC 1193 cache. Any attempt to register a binding between the protocol 1194 address and an NBMA address when this bit is set MUST be rejected 1195 with a Code of "14 - Unique Internetworking Layer Address Already 1196 Registered" if the replying NHS already has a cache entry for the 1197 protocol address and the cache entry has the "uniqueness" bit 1198 set. A registration of a CIE's information is rejected when the 1199 CIE is returned with the Code field set to anything other than 1200 0x00. See the description of the uniqueness bit in NHRP 1201 Resolution Request section above for further details. When this 1202 bit is set only, only one CIE MAY be included in the NHRP 1203 Registration Request. 1205 Request ID 1206 The request ID has the same meaning as described in Section 1207 5.2.0.1. However, the request ID for NHRP Registrations which is 1208 maintained at each client MUST be kept in non-volatile memory so 1209 that when a client crashes and reregisters there will be no 1210 inconsistency in the NHS's database. In order to reduce the 1211 overhead associated with updating non-volatile memory, the actual 1212 updating need not be done with every increment of the Request ID 1213 but could be done, for example, every 50 or 100 increments. In 1214 this scenario, when a client crashes and reregisters it knows to 1215 add 100 to the value of the Request ID in the non-volatile memory 1216 before using the Request ID for subsequent registrations. 1218 One or more CIEs are specified in the NHRP Registration Request. 1219 Each CIE contains next hop information which a client is attempting 1220 to register with its servers. Generally, all fields in CIEs enclosed 1221 in NHRP Registration Requests are coded as described in Section 1222 5.2.0.1. However, if a station is only registering itself with the 1223 NHRP Registration Request then it MAY code the Cli Addr T/L, Cli 1224 SAddr T/L, and Cli Proto Len as zero which signifies that the client 1225 address information is to be taken from the source information in the 1226 common header (see Section 5.2.0.1). Below, further clarification is 1227 given for some fields in a CIE in the context of a NHRP Registration 1228 Request. 1230 Code 1231 This field is set to 0x00 in NHRP Registration Requests. 1233 Prefix Length 1235 This field may be used in a NHRP Registration Request to register 1236 equivalence information for the Client Protocol Address specified 1237 in the CIE of an NHRP Registration Request In the case of NHRP 1238 Registration Request, the Prefix Length specifies the equivalence 1239 class of addresses which match the first "Prefix Length" bit 1240 positions of the Client Protocol Address. If the "U" bit is set 1241 in the common header then this field MUST be set to 0xFF. 1243 The NHRP Registration Request is used to register an NHC's NHRP 1244 information with its NHSs. If an NHC is configured with the protocol 1245 address of a serving NHS then the NHC may place the NHS's protocol 1246 address in the Destination Protocol Address field of the NHRP 1247 Registration Request common header otherwise the NHC must place its 1248 own protocol address in the Destination Protocol Address field. 1250 When an NHS receives an NHRP Registration Request which has the 1251 Destination Protocol Address field set to an address which belongs to 1252 a LIS/LAG for which the NHS is serving then if the Destination 1253 Protocol Address field is equal to the Source Protocol Address field 1254 (which would happen if the NHC put its protocol address in the 1255 Destination Protocol Address) or the Destination Protocol Address 1256 field is equal to the protocol address of the NHS then the NHS 1257 processes the NHRP Registration Request after doing appropriate error 1258 checking (including any applicable policy checking). 1260 When an NHS receives an NHRP Registration Request which has the 1261 Destination Protocol Address field set to an address which does not 1262 belong to a LIS/LAG for which the NHS is serving then the NHS 1263 forwards the packet down the routed path toward the appropriate 1264 LIS/LAG. 1266 When an NHS receives an NHRP Registration Request which has the 1267 Destination Protocol Address field set to an address which belongs to 1268 a LIS/LAG for which the NHS is serving then if the Destination 1269 Protocol Address field does not equal the Source Protocol Address 1270 field and the Destination Protocol Address field does not equal the 1271 protocol address of the NHS then the NHS forwards the message to the 1272 appropriate NHS within the LIS/LAG as specified by Destination 1273 Protocol Address field. 1275 It is possible that a misconfigured station will attempt to register 1276 with the wrong NHS (i.e., one that cannot serve it due to policy 1277 constraints or routing state). If this is the case, the NHS MUST 1278 reply with a NAK-ed Registration Reply of type Can't Serve This 1279 Address. 1281 If an NHS cannot serve a station due to a lack of resources, the NHS 1282 MUST reply with a NAK-ed Registration Reply of type Registration 1283 Overflow. 1285 In order to keep the registration entry from being discarded, the 1286 station MUST re-send the NHRP Registration Request packet often 1287 enough to refresh the registration, even in the face of occasional 1288 packet loss. It is recommended that the NHRP Registration Request 1289 packet be sent at an interval equal to one-third of the Holding Time 1290 specified therein. 1292 5.2.4 NHRP Registration Reply 1294 The NHRP Registration Reply is sent by an NHS to a client in response 1295 to that client's NHRP Registration Request. If the Code field of a 1296 CIE in the NHRP Registration Reply has anything other than zero in it 1297 then the NHRP Registration Reply is a NAK otherwise the reply is an 1298 ACK. The NHRP Registration Reply has a Type code of 4. 1300 An NHRP Registration Reply is formed from an NHRP Registration 1301 Request by changing the type code to 4, updating the CIE Code field, 1302 and filling in the appropriate extensions if they exist. The message 1303 specific meanings of the fields are as follows: 1305 Attempts to register the information in the CIEs of an NHRP 1306 Registration Request may fail for various reasons. If this is the 1307 case then each failed attempt to register the information in a CIE of 1308 an NHRP Registration Request is logged in the associated NHRP 1309 Registration Reply by setting the CIE Code field to the appropriate 1310 error code as shown below: 1312 CIE Code 1314 0 - Successful Registration 1316 The information in the CIE was successfully registered with the 1317 NHS. 1319 4 - Administratively Prohibited 1321 An NHS may refuse an NHRP Registration Request attempt for 1322 administrative reasons (due to policy constraints or routing 1323 state). If so, the NHS MUST send an NHRP Registration Reply 1324 which contains a NAK code of 4. 1326 5 - Insufficient Resources 1328 If an NHS cannot serve a station due to a lack of resources, 1329 the NHS MUST reply with a NAKed NHRP Registration Reply which 1330 contains a NAK code of 5. 1332 14 - Unique Internetworking Layer Address Already Registered 1333 If a client tries to register a protocol address to NBMA 1334 address binding with the uniqueness bit on and the protocol 1335 address already exists in the NHS's cache then if that cache 1336 entry also has the uniqueness bit on then this NAK Code is 1337 returned in the CIE in the NHRP Registration Reply. 1339 Due to the possible existence of asymmetric routing, an NHRP 1340 Registration Reply may not be able to merely follow the routed path 1341 back to the source protocol address specified in the common header of 1342 the NHRP Registration Reply. As a result, there MUST exist a direct 1343 NBMA level connection between the NHC and its NHS on which to send 1344 the NHRP Registration Reply before NHRP Registration Reply may be 1345 returned to the NHC. If such a connection does not exist then the 1346 NHS must setup such a connection to the NHC by using the source NBMA 1347 information supplied in the common header of the NHRP Registration 1348 Request. 1350 5.2.5 NHRP Purge Request 1352 The NHRP Purge Request packet is sent in order to invalidate cached 1353 information in a station. The NHRP Purge Request packet has a type 1354 code of 5. The mandatory part of an NHRP Purge Request is coded as 1355 described in Section 5.2.0.1. The message specific meanings of the 1356 fields are as follows: 1358 Flags - The flags field is coded as follows: 1360 0 1 1361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 |N| unused | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 N 1366 When set, this bit tells the receiver of the NHRP Purge Request 1367 that the requester does not expect to receive an NHRP Purge 1368 Reply. If an unsolicited NHRP Purge Reply is received by a 1369 station where that station is identified in the Source Protocol 1370 Address of the packet then that packet must be ignored. 1372 One or more CIEs are specified in the NHRP Purge Request. Each CIE 1373 contains next hop information which is to be purged from an NHS/NHC 1374 cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests 1375 are coded as described in Section 5.2.0.1. Below, further 1376 clarification is given for some fields in a CIE in the context of a 1377 NHRP Purge Request. 1379 Code 1380 This field is set to 0x00 in NHRP Purge Requests. 1382 Prefix Length 1384 In the case of NHRP Purge Requests, the Prefix Length specifies 1385 the equivalence class of addresses which match the first "Prefix 1386 Length" bit positions of the Client Protocol Address specified in 1387 the CIE. All next hop information which contains a protocol 1388 address which matches an element of this equivalence class is to 1389 be purged from the receivers cache. 1391 The Maximum Transmission Unit and Preference fields of the CIE are 1392 coded as zero. The Holding Time should be coded as zero but there 1393 may be some utility in supplying a "short" holding time to be 1394 applied to the matching next hop information before that 1395 information would be purged; this usage is for further study. The 1396 Client Protocol Address field and the Cli Proto Len field MUST be 1397 filled in. The Client Protocol Address is filled in with the 1398 protocol address to be purged from the receiving station's cache 1399 while the Cli Proto Len is set the length of the purged client's 1400 protocol address. All remaining fields in the CIE MAY be set to 1401 zero although the client NBMA information (and associated length 1402 fields) MAY be specified to narrow the scope of the NHRP Purge 1403 Request if requester desires. However, the receiver of an NHRP 1404 Purge Request may choose to ignore the Client NBMA information if 1405 it is supplied. 1407 An NHRP Purge Request packet is sent from an NHS to a station to 1408 cause it to delete previously cached information. This is done when 1409 the information may be no longer valid (typically when the NHS has 1410 previously provided next hop information for a station that is not 1411 directly connected to the NBMA subnetwork, and the egress point to 1412 that station may have changed). 1414 An NHRP Purge Request packet may also be sent from an NHC to an NHS 1415 with which the NHC had previously registered. This allows for an NHC 1416 to invalidate its registration with NHRP before it would otherwise 1417 expire via the holding timer. If an NHC does not have knowledge of a 1418 protocol address of a serving NHS then the NHC must place its own 1419 protocol address in the Destination Protocol Address field and 1420 forward the packet along the routed path. Otherwise, the NHC must 1421 place the protocol address of a serving NHS in this field. 1423 Serving NHSs may need to send one or more new NHRP Purge Requests as 1424 a result of receiving a purge from one of their served NHCs since the 1425 NHS may have previously responded to NHRP Resolution Requests for 1426 that NHC's NBMA information. These purges are "new" in that they are 1427 sourced by the NHS and not the NHC; that is, for each NHC that 1428 previously sent a NHRP Resolution Request for the purged NHC NBMA 1429 information, an NHRP Purge Request is sent which contains the Source 1430 Protocol/NBMA Addresses of the NHS and the Destination Protocol 1431 Address of the NHC which previously sent an NHRP Resolution Request 1432 prior to the purge. 1434 The station sending the NHRP Purge Request MAY periodically 1435 retransmit the NHRP Purge Request until either NHRP Purge Request is 1436 acknowledged or until the holding time of the information being 1437 purged has expired. Retransmission strategies for NHRP Purge Requests 1438 are a local matter. 1440 When a station receives an NHRP Purge Request, it MUST discard any 1441 previously cached information that matches the information in the 1442 CIEs. 1444 An NHRP Purge Reply MUST be returned for the NHRP Purge Request even 1445 if the station does not have a matching cache entry assuming that the 1446 "N" bit is off in the NHRP Purge Request. 1448 If the station wishes to reestablish communication with the 1449 destination shortly after receiving an NHRP Purge Request, it should 1450 make an authoritative NHRP Resolution Request in order to avoid any 1451 stale cache entries that might be present in intermediate NHSs (See 1452 section 6.2.2.). It is recommended that authoritative NHRP 1453 Resolution Requests be made for the duration of the holding time of 1454 the old information. 1456 5.2.6 NHRP Purge Reply 1458 The NHRP Purge Reply packet is sent in order to assure the sender of 1459 an NHRP Purge Request that all cached information of the specified 1460 type has been purged from the station sending the reply. The NHRP 1461 Purge Reply has a type code of 6. 1463 An NHRP Purge Reply is formed from an NHRP Purge Request by merely 1464 changing the type code in the request to 6. The packet is then 1465 returned to the requester after filling in the appropriate extensions 1466 if they exist. 1468 5.2.7 NHRP Error Indication 1470 The NHRP Error Indication is used to convey error indications to the 1471 sender of an NHRP packet. It has a type code of 7. The Mandatory 1472 Part has the following format: 1474 0 1 2 3 1475 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 1476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1477 | Src Proto Len | Dst Proto Len | unused | 1478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 | Error Code | Error Offset | 1480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1481 | Source NBMA Address (variable length) | 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Source NBMA Subaddress (variable length) | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | Source Protocol Address (variable length) | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | Destination Protocol Address (variable length) | 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Contents of NHRP Packet in error (variable length) | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 Src Proto Len 1493 This field holds the length in octets of the Source Protocol 1494 Address. 1496 Dst Proto Len 1497 This field holds the length in octets of the Destination Protocol 1498 Address. 1500 Error Code 1501 An error code indicating the type of error detected, chosen from 1502 the following list: 1504 1 - Unrecognized Extension 1506 When the Compulsory bit of an extension in NHRP packet is set, 1507 the NHRP packet cannot be processed unless the extension has 1508 been processed. The responder MUST return an NHRP Error 1509 Indication of type Unrecognized Extension if it is incapable of 1510 processing the extension. However, if a transit NHS (one which 1511 is not going to generate a reply) detects an unrecognized 1512 extension, it SHALL ignore the extension. 1514 3 - NHRP Loop Detected 1516 A Loop Detected error is generated when it is determined that 1517 an NHRP packet is being forwarded in a loop. 1519 6 - Protocol Address Unreachable 1521 This error occurs when a packet it moving along the routed path 1522 and it reaches a point such that the protocol address of 1523 interest is not reachable. 1525 7 - Protocol Error 1527 A generic packet processing error has occurred (e.g., invalid 1528 version number, invalid protocol type, failed checksum, etc.) 1530 8 - NHRP SDU Size Exceeded 1532 If the SDU size of the NHRP packet exceeds the MTU size of the 1533 NBMA network then this error is returned. 1535 9 - Invalid Extension 1537 If an NHS finds an extension in a packet which is inappropriate 1538 for the packet type, an error is sent back to the sender with 1539 Invalid Extension as the code. 1541 10 - Invalid NHRP Resolution Reply Received 1543 If a client receives a NHRP Resolution Reply for a Next Hop 1544 Resolution Request which it believes it did not make then an 1545 error packet is sent to the station making the reply with an 1546 error code of Invalid Reply Received. 1548 11 - Authentication Failure 1550 If a received packet fails an authentication test then this 1551 error is returned. 1553 15 - Hop Count Exceeded 1554 The hop count which was specified in the Fixed Header of an 1555 NHRP message has been exceeded. 1557 Error Offset 1558 The offset in octets into the original NHRP packet in which an 1559 error was detected. This offset is calculated starting from the 1560 NHRP Fixed Header. 1562 Source NBMA Address 1563 The Source NBMA address field is the address of the station which 1564 observed the error. 1566 Source NBMA SubAddress 1567 The Source NBMA subaddress field is the address of the station 1568 which observed the error. If the field's length as specified in 1569 ar$sstl is 0 then no storage is allocated for this address at all. 1571 Source Protocol Address 1572 This is the protocol address of the station which issued the Error 1573 packet. 1575 Destination Protocol Address 1576 This is the protocol address of the station which sent the packet 1577 which was found to be in error. 1579 An NHRP Error Indication packet SHALL NEVER be generated in response 1580 to another NHRP Error Indication packet. When an NHRP Error 1581 Indication packet is generated, the offending NHRP packet SHALL be 1582 discarded. In no case should more than one NHRP Error Indication 1583 packet be generated for a single NHRP packet. 1585 If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA 1586 and Source Protocol address fields of a transiting NHRP Error 1587 Indication packet then the NHS will quietly drop the packet and do 1588 nothing (this scenario would occur when the NHRP Error Indication 1589 packet was itself in a loop). 1591 Note that no extensions may be added to an NHRP Error Indication. 1593 5.3 Extensions Part 1595 The Extensions Part, if present, carries one or more extensions in 1596 {Type, Length, Value} triplets. 1598 Extensions have the following format: 1600 0 1 2 3 1601 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 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 |C|u| Type | Length | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Value... | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1608 C 1609 "Compulsory." If clear, and the NHS does not recognize the type 1610 code, the extension may safely be ignored. If set, and the NHS 1611 does not recognize the type code, the NHRP "request" is considered 1612 to be in error. (See below for details.) 1614 u 1615 Unused and must be set to zero. 1617 Type 1618 The extension type code (see below). The extension type is not 1619 qualified by the Compulsory bit, but is orthogonal to it. 1621 Length 1622 The length in octets of the value (not including the Type and 1623 Length fields; a null extension will have only an extension header 1624 and a length of zero). 1626 When extensions exist, the extensions list is terminated by the Null 1627 TLV, having Type = 0 and Length = 0. 1629 Extensions may occur in any order, but any particular extension type 1630 may occur only once in an NHRP packet unless explicitly stated to the 1631 contrary in the extensions definition. For example, the vendor- 1632 private extension may occur multiple times in a packet in order to 1633 allow for extensions which do not share the same vendor ID to be 1634 represented. It is RECOMMENDED that a given vendor include no more 1635 than one Vendor Private Extension. 1637 An NHS MUST NOT change the order of extensions. That is, the order 1638 of extensions placed in an NHRP packet by an NHC (or by an NHS when 1639 an NHS sources a packet) MUST be preserved as the packet moves 1640 between NHSs. Minimal NHC implementations MUST only recognize, but 1641 not necessarily parse, the Vendor Private extension and the End Of 1642 Extensions extension. Extensions are only present in a "reply" if 1643 they were present in the corresponding "request" with the exception 1644 of Vendor Private extensions. The previous statement is not intended 1645 to preclude the creation of NHS-only extensions which might be added 1646 to and removed from NHRP packets by the same NHS; such extensions 1647 MUST not be propagated to NHCs. 1649 The Compulsory bit provides for a means to add to the extension set. 1650 If the bit is set in an extension then the station responding to the 1651 NHRP message which contains that extension MUST be able to understand 1652 the extension (in this case, the station responding to the message is 1653 the station that would issue an NHRP reply in response to a NHRP 1654 request). As a result, the responder MUST return an NHRP Error 1655 Indication of type Unrecognized Extension. If the Compulsory bit is 1656 clear then the extension can be safely ignored; however, if an 1657 ignored extension is in a "request" then it MUST be returned, 1658 unchanged, in the corresponding "reply" packet type. 1660 If a transit NHS (one which is not going to generate a "reply") 1661 detects an unrecognized extension, it SHALL ignore the extension. If 1662 the Compulsory bit is set, the transit NHS MUST NOT cache the 1663 information contained in the packet and MUST NOT identify itself as 1664 an egress router (in the Forward Record or Reverse Record 1665 extensions). Effectively, this means, if a transit NHS encounters an 1666 extension which it cannot process and which has the Compulsory bit 1667 set then that NHS MUST NOT participate in any way in the protocol 1668 exchange other than acting as a forwarding agent. 1670 The NHRP extension Type space is subdivided to encourage use outside 1671 the IETF. 1673 0x0000 - 0x0FFF Reserved for NHRP. 1674 0x1000 - 0x11FF Allocated to the ATM Forum. 1675 0x1200 - 0x37FF Reserved for the IETF. 1676 0x3800 - 0x3FFF Experimental use. 1678 IANA will administer the ranges reserved for the IETF as described in 1679 Section 9. Values in the 'Experimental use' range have only local 1680 significance. 1682 5.3.0 The End Of Extensions 1684 Compulsory = 1 1685 Type = 0 1686 Length = 0 1688 When extensions exist, the extensions list is terminated by the End 1689 Of Extensions/Null TLV. 1691 5.3.1 Responder Address Extension 1693 Compulsory = 1 1694 Type = 3 1695 Length = variable 1697 This extension is used to determine the address of the NHRP 1698 responder; i.e., the entity that generates the appropriate "reply" 1699 packet for a given "request" packet. In the case of an NHRP 1700 Resolution Request, the station responding may be different (in the 1701 case of cached replies) than the system identified in the Next Hop 1702 field of the NHRP Resolution Reply. Further, this extension may aid 1703 in detecting loops in the NHRP forwarding path. 1705 This extension uses a single CIE with the extension specific meanings 1706 of the fields set as follows: 1708 The Prefix Length fields MUST be set to 0 and ignored. 1710 CIE Code 1711 5 - Insufficient Resources 1712 If the responder to an NHRP Resolution Request is an egress point 1713 for the target of the address resolution request (i.e., it is one 1714 of the stations identified in the list of CIEs in an NHRP 1715 Resolution Reply) and the Responder Address extension is included 1716 in the NHRP Resolution Request and insufficient resources to 1717 setup a cut-through VC exist at the responder then the Code field 1718 of the Responder Address Extension is set to 5 in order to tell 1719 the client that a VC setup attempt would in all likelihood be 1720 rejected; otherwise this field MUST be coded as a zero. NHCs MAY 1721 use this field to influence whether they attempt to setup a cut- 1722 through to the egress router. 1724 Maximum Transmission Unit 1725 This field gives the maximum transmission unit preferred by the 1726 responder. If this value is 0 then either the default MTU is used 1727 or the MTU negotiated via signaling is used if such negotiation is 1728 possible for the given NBMA. 1730 Holding Time 1731 The Holding Time field specifies the number of seconds for which 1732 the NBMA information of the responser is considered to be valid. 1733 Cached information SHALL be discarded when the holding time 1734 expires. 1736 "Client Address" information is actually "Responder Address" 1737 information for this extension. Thus, for example, Cli Addr T/L is 1738 the responder NBMA address type and length field. 1740 If a "requester" desires this information, the "requester" SHALL 1741 include this extension with a value of zero. Note that this implies 1742 that no storage is allocated for the Holding Time and Type/Length 1743 fields until the "Value" portion of the extension is filled out. 1745 If an NHS is generating a "reply" packet in response to a "request" 1746 containing this extension, the NHS SHALL include this extension, 1747 containing its protocol address in the "reply". If an NHS has more 1748 than one protocol address, it SHALL use the same protocol address 1749 consistently in all of the Responder Address, Forward Transit NHS 1750 Record, and Reverse Transit NHS Record extensions. The choice of 1751 which of several protocol address to include in this extension is a 1752 local matter. 1754 If an NHRP Resolution Reply packet being forwarded by an NHS contains 1755 a protocol address of that NHS in the Responder Address Extension 1756 then that NHS SHALL generate an NHRP Error Indication of type "NHRP 1757 Loop Detected" and discard the NHRP Resolution Reply. 1759 If an NHRP Resolution Reply packet is being returned by an 1760 intermediate NHS based on cached data, it SHALL place its own address 1761 in this extension (differentiating it from the address in the Next 1762 Hop field). 1764 5.3.2 NHRP Forward Transit NHS Record Extension 1766 Compulsory = 1 1767 Type = 4 1768 Length = variable 1770 The NHRP Forward Transit NHS record contains a list of transit NHSs 1771 through which a "request" has traversed. Each NHS SHALL append to 1772 the extension a Forward Transit NHS element (as specified below) 1773 containing its Protocol address. The extension length field and the 1774 ar$chksum fields SHALL be adjusted appropriately. 1776 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1777 this extension. 1779 In addition, NHSs that are willing to act as egress routers for 1780 packets from the source to the destination SHALL include information 1781 about their NBMA Address. 1783 This extension uses a single CIE per NHS Record element with the 1784 extension specific meanings of the fields set as follows: 1786 The Prefix Length fields MUST be set to 0 and ignored. 1788 CIE Code 1789 5 - Insufficient Resources 1790 If an NHRP Resolution Request contains an NHRP Forward Transit 1791 NHS Record Extension and insufficient resources to setup a cut- 1792 through VC exist at the current transit NHS then the CIE Code 1793 field for NHRP Forward Transit NHS Record Extension is set to 5 1794 in order to tell the client that a VC setup attempt would in all 1795 likelihood be rejected; otherwise this field MUST be coded as a 1796 zero. NHCs MAY use this field to influence whether they attempt 1797 to setup a cut-through as described in Section 2.2. Note that 1798 the NHRP Reverse Transit NHS Record Extension MUST always have 1799 this field set to zero. 1801 Maximum Transmission Unit 1802 This field gives the maximum transmission unit preferred by the 1803 transit NHS. If this value is 0 then either the default MTU is 1804 used or the MTU negotiated via signaling is used if such 1805 negotiation is possible for the given NBMA. 1807 Holding Time 1808 The Holding Time field specifies the number of seconds for which 1809 the NBMA information of the transit NHS is considered to be valid. 1810 Cached information SHALL be discarded when the holding time 1811 expires. 1813 "Client Address" information is actually "Forward Transit NHS 1814 Address" information for this extension. Thus, for example, Cli Addr 1815 T/L is the transit NHS NBMA address type and length field. 1817 If a "requester" wishes to obtain this information, it SHALL include 1818 this extension with a length of zero. Note that this implies that no 1819 storage is allocated for the Holding Time and Type/Length fields 1820 until the "Value" portion of the extension is filled out. 1822 If an NHS has more than one Protocol address, it SHALL use the same 1823 Protocol address consistently in all of the Responder Address, 1824 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1825 which of several Protocol addresses to include in this extension is a 1826 local matter. 1828 If a "request" that is being forwarded by an NHS contains the 1829 Protocol Address of that NHS in one of the Forward Transit NHS 1830 elements then the NHS SHALL generate an NHRP Error Indication of type 1831 "NHRP Loop Detected" and discard the "request". 1833 5.3.3 NHRP Reverse Transit NHS Record Extension 1835 Compulsory = 1 1836 Type = 5 1837 Length = variable 1839 The NHRP Reverse Transit NHS record contains a list of transit NHSs 1840 through which a "reply" has traversed. Each NHS SHALL append a 1841 Reverse Transit NHS element (as specified below) containing its 1842 Protocol address to this extension. The extension length field and 1843 ar$chksum SHALL be adjusted appropriately. 1845 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1846 this extension. 1848 In addition, NHSs that are willing to act as egress routers for 1849 packets from the source to the destination SHALL include information 1850 about their NBMA Address. 1852 This extension uses a single CIE per NHS Record element with the 1853 extension specific meanings of the fields set as follows: 1855 The CIE Code and Prefix Length fields MUST be set to 0 and ignored. 1857 Maximum Transmission Unit 1858 This field gives the maximum transmission unit preferred by the 1859 transit NHS. If this value is 0 then either the default MTU is 1860 used or the MTU negotiated via signaling is used if such 1861 negotiation is possible for the given NBMA. 1863 Holding Time 1864 The Holding Time field specifies the number of seconds for which 1865 the NBMA information of the transit NHS is considered to be valid. 1866 Cached information SHALL be discarded when the holding time 1867 expires. 1869 "Client Address" information is actually "Reverse Transit NHS 1870 Address" information for this extension. Thus, for example, Cli Addr 1871 T/L is the transit NHS NBMA address type and length field. 1873 If a "requester" wishes to obtain this information, it SHALL include 1874 this extension with a length of zero. Note that this implies that no 1875 storage is allocated for the Holding Time and Type/Length fields 1876 until the "Value" portion of the extension is filled out. 1878 If an NHS has more than one Protocol address, it SHALL use the same 1879 Protocol address consistently in all of the Responder Address, 1880 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1881 which of several Protocol addresses to include in this extension is a 1882 local matter. 1884 If a "reply" that is being forwarded by an NHS contains the Protocol 1885 Address of that NHS in one of the Reverse Transit NHS elements then 1886 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop 1887 Detected" and discard the "reply". 1889 Note that this information may be cached at intermediate NHSs; if 1890 so, the cached value SHALL be used when generating a reply. 1892 5.3.4 NHRP Authentication Extension 1894 Compulsory = 1 Type = 7 Length = variable 1896 The NHRP Authentication Extension is carried in NHRP packets to 1897 convey authentication information between NHRP speakers. The 1898 Authentication Extension may be included in any NHRP "request" or 1899 "reply" only. 1901 The authentication is always done pairwise on an NHRP hop-by-hop 1902 basis; i.e., the authentication extension is regenerated at each 1903 hop. If a received packet fails the authentication test, the station 1904 SHALL generate an Error Indication of type "Authentication Failure" 1905 and discard the packet. Note that one possible authentication failure 1906 is the lack of an Authentication Extension; the presence or absence 1907 of the Authentication Extension is a local matter. 1909 5.3.4.1 Header Format 1911 The authentication header has the following format: 1913 0 1 2 3 1914 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 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 | Reserved | Security Parameter Index (SPI)| 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 | Src Addr... | 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | | 1921 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1922 | | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 Security Parameter Index (SPI) can be thought of as an index into a 1926 table that maintains the keys and other information such as hash 1927 algorithm. Src and Dst communicate either offline using manual keying 1928 or online using a key management protocol to populate this table. The 1929 sending NHRP entity always allocates the SPI and the parameters 1930 associated with it. 1932 Src Addr a variable length field is the address assigned to the 1933 outgoing interface. The length of the addr is obtained from the 1934 source protocol length field in the mandatory part of the NHRP 1935 header. The tuple uniquely identifies the key and 1936 other parameters that are used in authentication. 1938 The length of the authentication data field is dependent on the hash 1939 algorithm used. The data field contains the keyed hash calculated 1940 over the entire NHRP payload. The authentication data field is zeroed 1941 out before the hash is calculated. 1943 5.3.4.2 SPI and Security Parameters Negotiation 1945 SPI's can be negotiated either manually or using an Internet Key 1946 Management protocol. Manual keying MUST be supported. The following 1947 parameters are associated with the tuple - lifetime, 1948 Algorithm, Key. Lifetime indicates the duration in seconds for which 1949 the key is valid. In case of manual keying, this duration can be 1950 infinite. Also, in order to better support manual keying, there may 1951 be multiple tuples active at the same time (Dst being the same). 1953 Algorithm specifies the hash algorithm agreed upon by the two 1954 entities. HMAC-MD5-128 [16] is the default algorithm. Other 1955 algorithms MAY be supported by defining new values. IANA will assign 1956 the numbers to identify the algorithm being used as described in 1957 Section 9. 1959 Any Internet standard key management protocol MAY so be used to 1960 negotiate the SPI and parameters. 1962 5.3.4.3 Message Processing 1964 At the time of adding the authentication extension header, src looks 1965 up in a table to fetch the SPI and the security parameters based on 1966 the outgoing interface address. If there are no entries in the table 1967 and if there is support for key management, the src initiates the key 1968 management protocol to fetch the necessary parameters. The src 1969 constructs the Authentication Extension payload and calculates the 1970 hash by zeroing authentication data field. The result replaces in the 1971 zeroed authentication data field. The src address field in the 1972 payload is the IP address assigned to the outgoing interface. 1974 If key management is not supported and authentication is mandatory, 1975 the packet is dropped and this information is logged. 1977 On the receiving end, dst fetches the parameters based on the SPI and 1978 the ip address in the authentication extension payload. The 1979 authentication data field is extracted before zeroing out to 1980 calculate the hash. It computes the hash on the entire payload and if 1981 the hash does not match, then an "abnormal event" has occurred. 1983 5.3.4.4 Security Considerations 1985 It is important that the keys chosen are strong as the security of 1986 the entire system depends on the keys being chosen properly and the 1987 correct implementation of the algorithms. 1989 The security is performed on a hop by hop basis. The data received 1990 can be trusted only so much as one trusts all the entities in the 1991 path traversed. 1993 5.3.5 NHRP Vendor-Private Extension 1995 Compulsory = 0 1996 Type = 8 1997 Length = variable 1999 The NHRP Vendor-Private Extension is carried in NHRP packets to 2000 convey vendor-private information or NHRP extensions between NHRP 2001 speakers. 2003 0 1 2 3 2004 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 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | Vendor ID | Data.... | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 Vendor ID 2010 802 Vendor ID as assigned by the IEEE [6] 2012 Data 2013 The remaining octets after the Vendor ID in the payload are 2014 vendor-dependent data. 2016 This extension may be added to any "request" or "reply" packet and it 2017 is the only extension that may be included multiple times. If the 2018 receiver does not handle this extension, or does not match the Vendor 2019 ID in the extension then the extension may be completely ignored by 2020 the receiver. If a Vendor Private Extension is included in a 2021 "request" then it must be copied to the corresponding "reply". 2023 6. Protocol Operation 2025 In this section, we discuss certain operational considerations of 2026 NHRP. 2028 6.1 Router-to-Router Operation 2030 In practice, the initiating and responding stations may be either 2031 hosts or routers. However, there is a possibility under certain 2032 conditions that a stable routing loop may occur if NHRP is used 2033 between two routers. In particular, attempting to establish an NHRP 2034 path across a boundary where information used in route selection is 2035 lost may result in a routing loop. Such situations include the loss 2036 of BGP path vector information, the interworking of multiple routing 2037 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 2038 circumstances, NHRP should not be used. This situation can be 2039 avoided if there are no "back door" paths between the entry and 2040 egress router outside of the NBMA subnetwork. Protocol mechanisms to 2041 relax these restrictions are under investigation. 2043 In general it is preferable to use mechanisms, if they exist, in 2044 routing protocols to resolve the egress point when the destination 2045 lies outside of the NBMA subnetwork, since such mechanisms will be 2046 more tightly coupled to the state of the routing system and will 2047 probably be less likely to create loops. 2049 6.2 Cache Management Issues 2051 The management of NHRP caches in the source station, the NHS serving 2052 the destination, and any intermediate NHSs is dependent on a number 2053 of factors. 2055 6.2.1 Caching Requirements 2057 Source Stations 2059 Source stations MUST cache all received NHRP Resolution Replies 2060 that they are actively using. They also must cache "incomplete" 2061 entries, i.e., those for which a NHRP Resolution Request has been 2062 sent but those for which an NHRP Resolution Reply has not been 2063 received. This is necessary in order to preserve the Request ID 2064 for retries, and provides the state necessary to avoid triggering 2065 NHRP Resolution Requests for every data packet sent to the 2066 destination. 2068 Source stations MUST purge expired information from their caches. 2070 Source stations MUST purge the appropriate cached information upon 2071 receipt of an NHRP Purge Request packet. 2073 When a station has a co-resident NHC and NHS, the co-resident NHS 2074 may reply to NHRP Resolution Requests from the co-resident NHC with 2075 information which the station cached as a result of the co-resident 2076 NHC making its own NHRP Resolution Requests as long as the co- 2077 resident NHS follows the rules for Transit NHSs as seen below. 2079 Serving NHSs 2081 The NHS serving the destination (the one which responds 2082 authoritatively to NHRP Resolution Requests) SHOULD cache protocol 2083 address information from all NHRP Resolution Requests to which it 2084 has responded if the information in the NHRP Resolution Reply has 2085 the possibility of changing during its lifetime (so that an NHRP 2086 Purge Request packet can be issued). The internetworking to NBMA 2087 binding information provided by the source station in the NHRP 2088 Resolution Request may also be cached if and only if the "S" bit is 2089 set, the NHRP Resolution Request has included a CIE with the 2090 Holding Time field set greater than zero (this is the valid Holding 2091 Time for the source binding), and only for non-authoritative use 2092 for a period not to exceed the Holding Time. 2094 Transit NHSs 2096 A Transit NHS (lying along the NHRP path between the source station 2097 and the responding NHS) may cache source binding information 2098 contained in NHRP Resolution Request packets that it forwards if 2099 and only if the "S" bit is set, the NHRP Resolution Request has 2100 included a CIE with the Holding Time field set greater than zero 2101 (this is the valid Holding Time for the source binding), and only 2102 for non-authoritative use for a period not to exceed the Holding 2103 Time. 2105 A Transit NHS may cache destination information contained in NHRP 2106 Resolution Reply CIE if only if the D bit is set and then only for 2107 non-authoritative use for a period not to exceed the Holding Time 2108 value contained in the CIE. A Transit NHS MUST NOT cache source 2109 binding information contained in an NHRP Resolution Reply. 2111 Further, a transit NHS MUST discard any cached information when the 2112 prescribed time has expired. It may return cached information in 2113 response to non-authoritative NHRP Resolution Requests only. 2115 6.2.2 Dynamics of Cached Information 2117 NBMA-Connected Destinations 2119 NHRP's most basic function is that of simple NBMA address 2120 resolution of stations directly attached to the NBMA subnetwork. 2121 These mappings are typically very static, and appropriately chosen 2122 holding times will minimize problems in the event that the NBMA 2123 address of a station must be changed. Stale information will cause 2124 a loss of connectivity, which may be used to trigger an 2125 authoritative NHRP Resolution Request and bypass the old data. In 2126 the worst case, connectivity will fail until the cache entry times 2127 out. 2129 This applies equally to information marked in NHRP Resolution 2130 Replies as being "stable" (via the "D" bit). 2132 Destinations Off of the NBMA Subnetwork 2134 If the source of an NHRP Resolution Request is a host and the 2135 destination is not directly attached to the NBMA subnetwork, and 2136 the route to that destination is not considered to be "stable," the 2137 destination mapping may be very dynamic (except in the case of a 2138 subnetwork where each destination is only singly homed to the NBMA 2139 subnetwork). As such the cached information may very likely become 2140 stale. The consequence of stale information in this case will be a 2141 suboptimal path (unless the internetwork has partitioned or some 2142 other routing failure has occurred). 2144 6.3 Use of the Prefix Length field of a CIE 2146 A certain amount of care needs to be taken when using the Prefix 2147 Length field of a CIE, in particular with regard to the prefix length 2148 advertised (and thus the size of the equivalence class specified by 2149 it). Assuming that the routers on the NBMA subnetwork are exchanging 2150 routing information, it should not be possible for an NHS to create a 2151 black hole by advertising too large of a set of destinations, but 2152 suboptimal routing (e.g., extra internetwork layer hops through the 2153 NBMA) can result. To avoid this situation an NHS that wants to send 2154 the Prefix Length MUST obey the following rule: 2156 The NHS examines the Network Layer Reachability Information (NLRI) 2157 associated with the route that the NHS would use to forward towards 2158 the destination (as specified by the Destination internetwork layer 2159 address in the NHRP Resolution Request), and extracts from this 2160 NLRI the shortest address prefix such that: (a) the Destination 2161 internetwork layer address (from the NHRP Resolution Request) is 2162 covered by the prefix, (b) the NHS does not have any routes with 2163 NLRI which form a subset of what is covered by the prefix. The 2164 prefix may then be used in the CIE. 2166 The Prefix Length field of the CIE should be used with restraint, in 2167 order to avoid NHRP stations choosing suboptimal transit paths when 2168 overlapping prefixes are available. This document specifies the use 2169 of the prefix length only when all the destinations covered by the 2170 prefix are "stable". That is, either: 2172 (a) All destinations covered by the prefix are on the NBMA network, or 2174 (b) All destinations covered by the prefix are directly attached to 2175 the NHRP responding station. 2177 Use of the Prefix Length field of the CIE in other circumstances is 2178 outside the scope of this document. 2180 6.4 Domino Effect 2182 One could easily imagine a situation where a router, acting as an 2183 ingress station to the NBMA subnetwork, receives a data packet, such 2184 that this packet triggers an NHRP Resolution Request. If the router 2185 forwards this data packet without waiting for an NHRP transit path to 2186 be established, then when the next router along the path receives the 2187 packet, the next router may do exactly the same - originate its own 2188 NHRP Resolution Request (as well as forward the packet). In fact 2189 such a data packet may trigger NHRP Resolution Request generation at 2190 every router along the path through an NBMA subnetwork. We refer to 2191 this phenomena as the NHRP "domino" effect. 2193 The NHRP domino effect is clearly undesirable. At best it may result 2194 in excessive NHRP traffic. At worst it may result in an excessive 2195 number of virtual circuits being established unnecessarily. 2196 Therefore, it is important to take certain measures to avoid or 2197 suppress this behavior. NHRP implementations for NHSs MUST provide a 2198 mechanism to address this problem. One possible strategy to address 2199 this problem would be to configure a router in such a way that NHRP 2200 Resolution Request generation by the router would be driven only by 2201 the traffic the router receives over its non-NBMA interfaces 2202 (interfaces that are not attached to an NBMA subnetwork). Traffic 2203 received by the router over its NBMA-attached interfaces would not 2204 trigger NHRP Resolution Requests. Such a router avoids the NHRP 2205 domino effect through administrative means. 2207 7. NHRP over Legacy BMA Networks 2209 There would appear to be no significant impediment to running NHRP 2210 over legacy broadcast subnetworks. There may be issues around 2211 running NHRP across multiple subnetworks. Running NHRP on broadcast 2212 media has some interesting possibilities; especially when setting up 2213 a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both 2214 end stations are legacy attached. This use for NHRP requires further 2215 research. 2217 8. Discussion 2219 The result of an NHRP Resolution Request depends on how routing is 2220 configured among the NHSs of an NBMA subnetwork. If the destination 2221 station is directly connected to the NBMA subnetwork and the routed 2222 path to it lies entirely within the NBMA subnetwork, the NHRP 2223 Resolution Replies always return the NBMA address of the destination 2224 station itself rather than the NBMA address of some egress router. 2225 On the other hand, if the routed path exits the NBMA subnetwork, NHRP 2226 will be unable to resolve the NBMA address of the destination, but 2227 rather will return the address of the egress router. For 2228 destinations outside the NBMA subnetwork, egress routers and routers 2229 in the other subnetworks should exchange routing information so that 2230 the optimal egress router may be found. 2232 In addition to NHSs, an NBMA station could also be associated with 2233 one or more regular routers that could act as "connectionless 2234 servers" for the station. The station could then choose to resolve 2235 the NBMA next hop or just send the packets to one of its 2236 connectionless servers. The latter option may be desirable if 2237 communication with the destination is short-lived and/or doesn't 2238 require much network resources. The connectionless servers could, of 2239 course, be physically integrated in the NHSs by augmenting them with 2240 internetwork layer switching functionality. 2242 9. IANA Considerations 2244 IANA will take advice from James Luciani (see author information 2245 below for contact information), who is the Area Director appointed 2246 designated subject matter expert, in order to assign numbers from the 2247 various number spaces described herein. In the event that the Area 2248 Director appointed designated subject matter expert is unavailable, 2249 the relevant IESG Area Director will appoint another expert. Any and 2250 all requests for value assignment within a given number space will be 2251 accepted when the usage of the value assignment documented. Possible 2252 forms of documentantion include, but is not limited to, RFCs or the 2253 product of another cooperative standards body (e.g., the MPOA and 2254 LANE subworking group of the ATM Forum). 2256 References 2258 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 2259 Govindan, RFC1735. 2261 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 2263 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 2265 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 2266 and D. Piscitello, RFC 1209. 2268 [5] Protocol Identification in the Network Layer, ISO/IEC TR 2269 9577:1990. 2271 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 2273 [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, 2274 RFC1483. 2276 [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, 2277 A. Malis, D. Robinson, and R. Ullmann, RFC1356. 2279 [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and 2280 A. Malis, RFC1490. 2282 [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, 2283 Yakov Rekhter, Dilip Kandlur, RFC1937. 2285 [11] Support for Multicast over UNI 3.0/3.1 based ATM Networks, 2286 G. Armitage, RFC2021 2288 [12] Server Cache Synchronization Protocol (SCSP) - NBMA, 2289 J. Luciani, G. Armitage, J. Halpern, draft-ietf-ion-scsp-02.txt 2291 [13] NHRP for Destinations off the NBMA Subnetwork, 2292 Y. Rekhter, Work In Progress. 2294 [14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress. 2296 [15] Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, 2297 RFC 2119. 2299 [16] "HMAC: Keyed Hashing for Message Authentication", Krawczyk, Bellare, 2300 Canetti, RFC 2104. 2302 Acknowledgments 2304 We would like to thank (in no particular order) Naganand Doraswamy of 2305 Bay Networks for the entirety of the security section, Thomas Narton 2306 of IBM for his comments in the role of Internet AD, Juha Heinenan of 2307 Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP 2308 and the original NHRP draft, which served as the basis for this work. 2309 Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of 2310 ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul 2311 Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, 2312 and Grenville Armitage of Bellcore should also be acknowledged for 2313 comments and suggestions that improved this work substantially. We 2314 would also like to thank the members of the ION working group of the 2315 IETF, whose review and discussion of this document have been 2316 invaluable. 2318 Authors' Addresses 2320 James V. Luciani Dave Katz 2321 Bay Networks cisco Systems 2322 3 Federal Street 170 W. Tasman Dr. 2323 Mail Stop: BL3-04 San Jose, CA 95134 USA 2324 Billerica, MA 01821 Phone: +1 408 526 8284 2325 Phone: +1 508 916 4734 Email: dkatz@cisco.com 2326 Email: luciani@baynetworks.com 2328 David Piscitello Bruce Cole 2329 Core Competence Juniper Networks 2330 1620 Tuckerstown Road 3260 Jay St. 2331 Dresher, PA 19025 USA Santa Clara, CA 95054 2332 Phone: +1 215 830 0692 Phone: +1 408 327 1900 2333 Email: dave@corecom.com Email: bcole@jnx.com