idnits 2.17.1 draft-ietf-rolc-nhrp-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 265: '...quest for a given destination MUST NOT...' RFC 2119 keyword, line 293: '... NHSs MUST NOT respond to authoritat...' RFC 2119 keyword, line 314: '...s not exists then one MUST be created....' RFC 2119 keyword, line 403: '... Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used...' RFC 2119 keyword, line 424: '... an NHC, the NHS MUST send NHRP messag...' (107 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 949 has weird spacing: '... wishes to r...' == Line 1926 has weird spacing: '...: fixed part ...' == 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 (September 1997) is 9714 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 523 -- Looks like a reference, but probably isn't: '0x00-00-5E' on line 523 -- Looks like a reference, but probably isn't: '0x00-03' on line 523 == Unused Reference: '2' is defined on line 2206, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2213, 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') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 18 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing over Large Clouds Working Group James V. Luciani 2 INTERNET-DRAFT (Bay Networks) 3 Dave Katz 4 (cisco Systems) 5 David Piscitello 6 (Core Competence, Inc.) 7 Bruce Cole 8 (Juniper Networks) 9 Expires September 1997 11 NBMA Next Hop Resolution Protocol (NHRP) 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 34 NHRP can be used by a source station (host or router) connected to a 35 Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the 36 internetworking layer address and NBMA subnetwork addresses of the 37 "NBMA next hop" towards a destination station. If the destination is 38 connected to the NBMA subnetwork, then the NBMA next hop is the 39 destination station itself. Otherwise, the NBMA next hop is the 40 egress router from the NBMA subnetwork that is "nearest" to the 41 destination station. NHRP is intended for use in a multiprotocol 42 internetworking layer environment over NBMA subnetworks. 44 Note that while this protocol was developed for use with NBMA 45 subnetworks, it is possible, if not likely, that it will be applied 46 to BMA subnetworks as well. However, this usage of NHRP is for 47 further study. 49 This document is intended to be a functional superset of the NBMA 50 Address Resolution Protocol (NARP) documented in [1]. 52 Operation of NHRP as a means of establishing a transit path across an 53 NBMA subnetwork between two routers will be addressed in a separate 54 document (see [13]). 56 1. Introduction 58 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 59 (a host or router), wishing to communicate over a Non-Broadcast, 60 Multi-Access (NBMA) subnetwork, to determine the internetworking 61 layer addresses and NBMA addresses of suitable "NBMA next hops" 62 toward a destination station. A subnetwork can be non-broadcast 63 either because it technically doesn't support broadcasting (e.g., an 64 X.25 subnetwork) or because broadcasting is not feasible for one 65 reason or another (e.g., an SMDS multicast group or an extended 66 Ethernet would be too large). If the destination is connected to the 67 NBMA subnetwork, then the NBMA next hop is the destination station 68 itself. Otherwise, the NBMA next hop is the egress router from the 69 NBMA subnetwork that is "nearest" to the destination station. 71 One way to model an NBMA network is by using the notion of logically 72 independent IP subnets (LISs). LISs, as defined in [3] and [4], have 73 the following properties: 75 1) All members of a LIS have the same IP network/subnet number 76 and address mask. 78 2) All members of a LIS are directly connected to the same 79 NBMA subnetwork. 81 3) All hosts and routers outside of the LIS are accessed via a router. 83 4) All members of a LIS access each other directly (without routers). 85 Address resolution as described in [3] and [4] only resolves the next 86 hop address if the destination station is a member of the same LIS as 87 the source station; otherwise, the source station must forward 88 packets to a router that is a member of multiple LIS's. In multi-LIS 89 configurations, hop-by-hop address resolution may not be sufficient 90 to resolve the "NBMA next hop" toward the destination station, and IP 91 packets may have multiple IP hops through the NBMA subnetwork. 93 Another way to model NBMA is by using the notion of Local Address 94 Groups (LAGs) [10]. The essential difference between the LIS and the 95 LAG models is that while with the LIS model the outcome of the 96 "local/remote" forwarding decision is driven purely by addressing 97 information, with the LAG model the outcome of this decision is 98 decoupled from the addressing information and is coupled with the 99 Quality of Service and/or traffic characteristics. With the LAG 100 model any two entities on a common NBMA network could establish a 101 direct communication with each other, irrespective of the entities' 102 addresses. 104 Support for the LAG model assumes the existence of a mechanism that 105 allows any entity (i.e., host or router) connected to an NBMA network 106 to resolve an internetworking layer address to an NBMA address for 107 any other entity connected to the same NBMA network. This resolution 108 would take place regardless of the address assignments to these 109 entities. Within the parameters described in this document, NHRP 110 describes such a mechanism. For example, when the internetworking 111 layer address is of type IP, once the NBMA next hop has been 112 resolved, the source may either start sending IP packets to the 113 destination (in a connectionless NBMA subnetwork such as SMDS) or may 114 first establish a connection to the destination with the desired 115 bandwidth (in a connection-oriented NBMA subnetwork such as ATM). 117 Use of NHRP may be sufficient for hosts doing address resolution when 118 those hosts are directly connected to an NBMA subnetwork, allowing 119 for straightforward implementations in NBMA stations. NHRP also has 120 the capability of determining the egress point from an NBMA 121 subnetwork when the destination is not directly connected to the NBMA 122 subnetwork and the identity of the egress router is not learned by 123 other methods (such as routing protocols). Optional extensions to 124 NHRP provide additional robustness and diagnosability. 126 Address resolution techniques such as those described in [3] and [4] 127 may be in use when NHRP is deployed. ARP servers and services over 128 NBMA subnetworks may be required to support hosts that are not 129 capable of dealing with any model for communication other than the 130 LIS model, and deployed hosts may not implement NHRP but may continue 131 to support ARP variants such as those described in [3] and [4]. NHRP 132 is intended to reduce or eliminate the extra router hops required by 133 the LIS model, and can be deployed in a non-interfering manner with 134 existing ARP services [14]. 136 The operation of NHRP to establish transit paths across NBMA 137 subnetworks between two routers requires additional mechanisms to 138 avoid stable routing loops, and will be described in a separate 139 document (see [13]). 141 2. Overview 143 2.1 Terminology 145 The term "network" is highly overloaded, and is especially confusing 146 in the context of NHRP. We use the following terms: 148 Internetwork layer--the media-independent layer (IP in the case of 149 TCP/IP networks). 151 Subnetwork layer--the media-dependent layer underlying the 152 internetwork layer, including the NBMA technology (ATM, X.25, SMDS, 153 etc.) 155 The term "server", unless explicitly stated to the contrary, refers 156 to an Next Hop Server (NHS). An NHS is an entity performing the 157 Next Hop Resolution Protocol service within the NBMA cloud. An NHS 158 is always tightly coupled with a routing entity (router, route 159 server or edge device) although the converse is not yet guaranteed 160 until ubiquitous deployment of this functionality occurs. Note 161 that the presence of intermediate routers that are not coupled with 162 an NHS entity may preclude the use of NHRP when source and 163 destination stations on different sides of such routers and thus 164 such routers may partition NHRP reachability within an NBMA 165 network. 167 The term "client", unless explicitly stated to the contrary, refers 168 to an Next Hop Resolution Protocol client (NHC). An NHC is an 169 entity which initiates NHRP requests of various types in order to 170 obtain access to the NHRP service. 172 The term "station" generally refers to a host or router which 173 contains an NHRP entity. Occasionally, the term station will 174 describe a "user" of the NHRP client or service functionality; the 175 difference in usage is largely semantic. 177 2.2 Protocol Overview 179 In this section, we briefly describe how a source S (which 180 potentially can be either a router or a host) uses NHRP to determine 181 the "NBMA next hop" to destination D. 183 For administrative and policy reasons, a physical NBMA subnetwork may 184 be partitioned into several, disjoint "Logical NBMA subnetworks". A 185 Logical NBMA subnetwork is defined as a collection of hosts and 186 routers that share unfiltered subnetwork connectivity over an NBMA 187 subnetwork. "Unfiltered subnetwork connectivity" refers to the 188 absence of closed user groups, address screening or similar features 189 that may be used to prevent direct communication between stations 190 connected to the same NBMA subnetwork. (Hereafter, unless otherwise 191 specified, we use the term "NBMA subnetwork" to mean *logical* NBMA 192 subnetwork.) 194 Placed within the NBMA subnetwork are one or more entities that 195 implement the NHRP protocol. Such stations which are capable of 196 answering NHRP Resolution Requests are known as "Next Hop Servers" 197 (NHSs). Each NHS serves a set of destination hosts, which may or may 198 not be directly connected to the NBMA subnetwork. NHSs cooperatively 199 resolve the NBMA next hop within their logical NBMA subnetwork. In 200 addition to NHRP, NHSs may support "classical" ARP service; however, 201 this will be the subject of a separate document [14]. 203 An NHS maintains a cache which contains protocol layer address to 204 NBMA subnetwork layer address resolution information. This cache can 205 be constructed from information obtained from NHRP Register packets 206 (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply 207 packets, or through mechanisms outside the scope of this document 208 (examples of such mechanisms might include ARP[3] and pre-configured 209 tables). Section 6.2 further describes cache management issues. 211 For a station within a given LIS to avoid providing NHS 212 functionality, there must be one or more NHSs within the NBMA 213 subnetwork which are providing authoritative address resolution 214 information on its behalf. Such an NHS is said to be "serving" the 215 station. A stations on a LIS that lacks NHS functionality and is a 216 client of the NHRP service is known as NHRP Client or just NHCs. If 217 a serving NHS is to be able to supply the address resolution 218 information for an NHC then NHSs must exist at each hop along all 219 routed paths between the NHC making the resolution request and the 220 destination NHC. The last NHRP entity along the routed path is the 221 serving NHS; that is, NHRP Resolution Requests are not forwarded to 222 destination NHCs but rather are processed by the serving NHS. 224 An NHC also maintains a cache of protocol address to NBMA address 225 resolution information. This cache is populated through information 226 obtained from NHRP Resolution Reply packets, from manual 227 configuration, or through mechanisms outside the scope of this 228 document. 230 The protocol proceeds as follows. An event occurs triggering station 231 S to want to resolve the NBMA address of a path to D. This is most 232 likely to be when a data packet addressed to station D is to be 233 emitted from station S (either because station S is a host, or 234 station S is a transit router), but the address resolution could also 235 be triggered by other means (a routing protocol update packet, for 236 example). Station S first determines the next hop to station D 237 through normal routing processes (for a host, the next hop may simply 238 be the default router; for routers, this is the "next hop" to the 239 destination internetwork layer address). If the destination's 240 address resolution information is already available in S's cache then 241 that information is used to forward the packet. Otherwise, if the 242 next hop is reachable through one of its NBMA interfaces, S 243 constructs an NHRP Resolution Request packet (see Section 5.2.1) 244 containing station D's internetwork layer address as the (target) 245 destination address, S's own internetwork layer address as the source 246 address (Next Hop Resolution Request initiator), and station S's NBMA 247 addressing information. Station S may also indicate that it prefers 248 an authoritative NHRP Resolution Reply (i.e., station S only wishes 249 to receive an NHRP Resolution Reply from an NHS serving the 250 destination NHC). Station S emits the NHRP Resolution Request packet 251 towards the destination. 253 If the NHRP Resolution Request is triggered by a data packet then S 254 may, while awaiting an NHRP Resolution Reply, choose to dispose of 255 the data packet in one of the following ways: 257 (a) Drop the packet 258 (b) Retain the packet until the NHRP Resolution Reply arrives 259 and a more optimal path is available 260 (c) Forward the packet along the routed path toward D 262 The choice of which of the above to perform is a local policy matter, 263 though option (c) is the recommended default, since it may allow data 264 to flow to the destination while the NBMA address is being resolved. 265 Note that an NHRP Resolution Request for a given destination MUST NOT 266 be triggered on every packet. 268 When the NHS receives an NHRP Resolution Request, a check is made to 269 see if it serves station D. If the NHS does not serve D, the NHS 270 forwards the NHRP Resolution Request to another NHS. Mechanisms for 271 determining how to forward the NHRP Resolution Request are discussed 272 in Section 3. 274 If this NHS serves D, the NHS resolves station D's NBMA address 275 information, and generates a positive NHRP Resolution Reply on D's 276 behalf. NHRP Resolution Replies in this scenario are always marked 277 as "authoritative". The NHRP Resolution Reply packet contains the 278 address resolution information for station D which is to be sent back 279 to S. Note that if station D is not on the NBMA subnetwork, the next 280 hop internetwork layer address will be that of the egress router 281 through which packets for station D are forwarded. 283 A transit NHS receiving an NHRP Resolution Reply may cache the 284 address resolution information contained therein. To a subsequent 285 NHRP Resolution Request, this NHS may respond with the cached, "non- 286 authoritative" address resolution information if the NHS is permitted 287 to do so (see Sections 5.2.2 and 6.2 for more information on non- 288 authoritative versus authoritative NHRP Resolution Replies). Non- 289 authoritative NHRP Resolution Replies are distinguished from 290 authoritative NHRP Resolution Replies so that if a communication 291 attempt based on non-authoritative information fails, a source 292 station can choose to send an authoritative NHRP Resolution Request. 293 NHSs MUST NOT respond to authoritative NHRP Resolution Requests with 294 cached information. 296 If the determination is made that no NHS in the NBMA subnetwork can 297 reply to the NHRP Resolution Request for D then a negative NHRP 298 Resolution Reply (NAK) is returned. This occurs when (a) no next-hop 299 resolution information is available for station D from any NHS, or 300 (b) an NHS is unable to forward the NHRP Resolution Request (e.g., 301 connectivity is lost). 303 NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, 304 and NHRP Error Indications follow a routed path in the same fashion 305 that NHRP Resolution Requests and NHRP Resolution Replies do. 306 Specifically, "requests" and "indications" follow the routed path 307 from Source Protocol Address (which is the address of the station 308 initiating the communication) to the Destination Protocol Address. 309 "Replies", on the other hand, follow the routed path from the 310 Destination Protocol Address back to the Source Protocol Address with 311 the following exceptions: in the case of a NHRP Registration Reply 312 and in the case of an NHC initiated NHRP Purge Request, the packet is 313 always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if 314 one does not exists then one MUST be created. 316 NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA 317 subnetwork however further study is being done in this area (see 318 Section 7). Thus, the internetwork layer data traffic out of and 319 into an NBMA subnetwork always traverses an internetwork layer router 320 at its border. 322 NHRP optionally provides a mechanism to send a NHRP Resolution Reply 323 which contains aggregated address resolution information. For 324 example, suppose that router X is the next hop from station S to 325 station D and that X is an egress router for all stations sharing an 326 internetwork layer address prefix with station D. When an NHRP 327 Resolution Reply is generated in response to a NHRP Resolution 328 Request, the responder may augment the internetwork layer address of 329 station D with a prefix length (see Section 5.2.0.1). A subsequent 330 (non-authoritative) NHRP Resolution Request for some destination that 331 shares an internetwork layer address prefix (for the number of bits 332 specified in the prefix length) with D may be satisfied with this 333 cached information. See section 6.2 regarding caching issues. 335 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 336 (e.g., X.25 closed user group facility, or SMDS address screens), to 337 trace the routed path that an NHRP packet takes, or to provide loop 338 detection and diagnostic capabilities, a "Route Record" may be 339 included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route 340 Record extensions are the NHRP Forward Transit NHS Record Extension 341 and the NHRP Reverse Transit NHS Record Extension. They contain the 342 internetwork (and subnetwork layer) addresses of all intermediate 343 NHSs between source and destination and between destination and 344 source respectively. When a source station is unable to communicate 345 with the responder (e.g., an attempt to open an SVC fails), it may 346 attempt to do so successively with other subnetwork layer addresses 347 in the NHRP Forward Transit NHS Record Extension until it succeeds 348 (if authentication policy permits such action). This approach can 349 find a suitable egress point in the presence of subnetwork-layer 350 filtering (which may be source/destination sensitive, for instance, 351 without necessarily creating separate logical NBMA subnetworks) or 352 subnetwork-layer congestion (especially in connection-oriented 353 media). 355 3. Deployment 357 NHRP Resolution Requests traverse one or more hops within an NBMA 358 subnetwork before reaching the station that is expected to generate a 359 response. Each station, including the source station, chooses a 360 neighboring NHS to which it will forward the NHRP Resolution Request. 361 The NHS selection procedure typically involves applying a destination 362 protocol layer address to the protocol layer routing table which 363 causes a routing decision to be returned. This routing decision is 364 then used to forward the NHRP Resolution Request to the downstream 365 NHS. The destination protocol layer address previously mentioned is 366 carried within the NHRP Resolution Request packet. Note that even 367 though a protocol layer address was used to acquire a routing 368 decision, NHRP packets are not encapsulated within a protocol layer 369 header but rather are carried at the NBMA layer using the 370 encapsulation described in Section 5. 372 Each NHS/router examines the NHRP Resolution Request packet on its 373 way toward the destination. Each NHS which the NHRP packet traverses 374 on the way to the packet's destination might modify the packet (e.g., 375 updating the Forward Record extension). Ignoring error situations, 376 the NHRP Resolution Request eventually arrives at a station that is 377 to generate an NHRP Resolution Reply. This responding station 378 "serves" the destination. The responding station generates an NHRP 379 Resolution Reply using the source protocol address from within the 380 NHRP packet to determine where the NHRP Resolution Reply should be 381 sent. 383 Rather than use routing to determine the next hop for an NHRP packet, 384 an NHS may use other applicable means (such as static configuration 385 information ) in order to determine to which neighboring NHSs to 386 forward the NHRP Resolution Request packet as long as such other 387 means would not cause the NHRP packet to arrive at an NHS which is 388 not along the routed path. The use of static configuration 389 information for this purpose is beyond the scope of this document. 391 The NHS serving a particular destination must lie along the routed 392 path to that destination. In practice, this means that all egress 393 routers must double as NHSs serving the destinations beyond them, and 394 that hosts on the NBMA subnetwork are served by routers that double 395 as NHSs. Also, this implies that forwarding of NHRP packets within 396 an NBMA subnetwork requires a contiguous deployment of NHRP capable 397 routers. It is important that, in a given LIS/LAG which is using 398 NHRP, all NHSs within the LIS/LAG have at least some portion of their 399 resolution databases synchronized so that a packet arriving at one 400 router/NHS in a given LIS/LAG will be forwarded in the same fashion 401 as packet arriving at a different router/NHS for the given LIS/LAG. 402 One method, among others, is to use the Server Cache Synchronization 403 Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used 404 when a LIS/LAG contains two or more router/NHSs. 406 During migration to NHRP, it cannot be expected that all routers 407 within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic 408 which would otherwise need to be forwarded through such routers can 409 be expected to be dropped due to the NHRP packet not being 410 recognized. In this case, NHRP will be unable to establish any 411 transit paths whose discovery requires the traversal of the non-NHRP 412 speaking routers. If the client has tried and failed to acquire a 413 cut through path then the client should use the network layer routed 414 path as a default. 416 If an NBMA technology offers a group, an anycast, or a multicast 417 addressing feature then the NHC may be configured with such an 418 address which would be assigned to the appropriate NHSs. The NHC 419 might then submit NHRP Resolution Requests to such an address, 420 eliciting a response from one or more NHSs, depending on the response 421 strategy selected. Note that the constraints described in Section 2 422 regarding directly sending NHRP Resolution Reply may apply. 424 When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined 425 for the NHC directly to the NHC. That is, the NHRP message MUST NOT 426 transit through any NHS which is not serving the NHC when the NHRP 427 message is currently at an NHS which does serve the NHC (this, of 428 course, assumes the NHRP message is destined for the NHC). Further, 429 an NHS which serves an NHC SHOULD have a direct NBMA level connection 430 to that NHC (see Section 5.2.3 and 5.2.4 for examples). 432 With the exception of NHRP Registration Requests (see Section 5.2.3 433 and 5.2.4 for details of the NHRP Registration Request case), an NHC 434 MUST send NHRP messages over a direct NBMA level connection between 435 the serving NHS and the served NHC. 437 It may not be desirable to maintain semi-permanent NBMA level 438 connectivity between the NHC and the NHS. In this case, when NBMA 439 level connectivity is initially setup between the NHS and the NHC (as 440 described in Section 5.2.4), the NBMA address of the NHS should be 441 obtained through the NBMA level signaling technology. This address 442 should be stored for future use in setting up subsequent NBMA level 443 connections. A somewhat more information rich technique to obtain 444 the address information (and more) of the serving NHS would be for 445 the NHC to include the Responder Address extension (see Section 446 5.3.1) in the NHRP Registration Request and to store the information 447 returned to the NHC in the Responder Address extension which is 448 subsequently included in the NHRP Registration Reply. Note also 449 that, in practice, a client's default router should also be its NHS; 450 thus a client may be able to know the NBMA address of its NHS from 451 the configuration which was already required for the client to be 452 able to communicate. Further, as mentioned in Section 4, NHCs may be 453 configured with the addressing information of one or more NHSs. 455 4. Configuration 457 Next Hop Clients 459 An NHC connected to an NBMA subnetwork MAY be configured with the 460 Protocol address(es) and NBMA address(es) of its NHS(s). The 461 NHS(s) will likely also represent the NHC's default or peer 462 routers, so their NBMA addresses may be obtained from the NHC's 463 existing configuration. If the NHC is attached to several 464 subnetworks (including logical NBMA subnetworks), the NHC should 465 also be configured to receive routing information from its NHS(s) 466 and peer routers so that it can determine which internetwork layer 467 networks are reachable through which subnetworks. 469 Next Hop Servers 471 An NHS is configured with knowledge of its own internetwork layer 472 and NBMA addresses. An NHS MAY also be configured with a set of 473 internetwork layer address prefixes that correspond to the 474 internetwork layer addresses of the stations it serves. The NBMA 475 addresses of the stations served by the NHS may be learned via NHRP 476 Registration packets. 478 If a served NHC is attached to several subnetworks, the 479 router/route-server coresident with the serving NHS may also need 480 to be configured to advertise routing information to such NHCs. 482 If an NHS acts as an egress router for stations connected to other 483 subnetworks than the NBMA subnetwork, the NHS must, in addition to 484 the above, be configured to exchange routing information between 485 the NBMA subnetwork and these other subnetworks. 487 In all cases, routing information is exchanged using conventional 488 intra-domain and/or inter-domain routing protocols. 490 5. NHRP Packet Formats 492 This section describes the format of NHRP packets. In the following, 493 unless otherwise stated explicitly, the unqualified term "request" 494 refers generically to any of the NHRP packet types which are 495 "requests". Further, unless otherwise stated explicitly, the 496 unqualified term "reply" refers generically to any of the NHRP packet 497 types which are "replies". 499 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 500 Extensions Part. The Fixed Part is common to all NHRP packet types. 501 The Mandatory Part MUST be present, but varies depending on packet 502 type. The Extensions Part also varies depending on packet type, and 503 need not be present. 505 The length of the Fixed Part is fixed at 20 octets. The length of 506 the Mandatory Part is determined by the contents of the extensions 507 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 508 length is equal to total packet length (ar$pktsz) minus 20 otherwise 509 the mandatory part length is equal to ar$extoff minus 20. The length 510 of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs 511 may increase the size of an NHRP packet as a result of extension 512 processing, but not beyond the offered maximum SDU size of the NBMA 513 network. 515 NHRP packets are actually members of a wider class of address mapping 516 and management protocols being developed by the IETF. A specific 517 encapsulation, based on the native formats used on the particular 518 NBMA network over which NHRP is carried, indicates the generic IETF 519 mapping and management protocol. For example, SMDS networks always 520 use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet 521 is preceded by the following LLC/SNAP encapsulation: 523 [0xAA-AA-03] [0x00-00-5E] [0x00-03] 525 The first three octets are LLC, indicating that SNAP follows. The 526 SNAP OUI portion is the IANA's OUI, and the SNAP PID portion 527 identifies the mapping and management protocol. A field in the Fixed 528 Header following the encapsulation indicates that it is NHRP. 530 ATM uses either LLC/SNAP encapsulation of each packet (including 531 NHRP), or uses no encapsulation on VCs dedicated to a single protocol 532 (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or 533 identification of NHRP, using a NLPID of 0x0080 and the same SNAP 534 contents as above (see [8], [9]). 536 Fields marked "unused" MUST be set to zero on transmission, and 537 ignored on receipt. 539 Most packet types (ar$op.type) have both internetwork layer 540 protocol-independent fields and protocol-specific fields. The 541 protocol type/snap fields (ar$pro.type/snap) qualify the format of 542 the protocol-specific fields. 544 5.1 NHRP Fixed Header 546 The Fixed Part of the NHRP packet contains those elements of the NHRP 547 packet which are always present and do not vary in size with the type 548 of packet. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | ar$afn | ar$pro.type | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | ar$pro.snap | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | ar$pro.snap | ar$hopcnt | ar$pktsz | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | ar$chksum | ar$extoff | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | ar$op.version | ar$op.type | ar$shtl | ar$sstl | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 ar$afn 565 Defines the type of "link layer" addresses being carried. This 566 number is taken from the 'address family number' list specified in 567 [6]. This field has implications to the coding of ar$shtl and 568 ar$sstl as described below. 570 ar$pro.type 571 field is a 16 bit unsigned integer representing the following 572 number space: 574 0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 575 0x0100 to 0x03FF Reserved for future use by the IETF. 576 0x0400 to 0x04FF Allocated for use by the ATM Forum. 577 0x0500 to 0x05FF Experimental/Local use. 578 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 580 (based on the observations that valid Ethertypes are never smaller 581 than 0x600, and NLPIDs never larger than 0xFF.) 583 ar$pro.snap 584 When ar$pro.type has a value of 0x0080, a SNAP encoded extension is 585 being used to encode the protocol type. This snap extension is 586 placed in the ar$pro.snap field. This is termed the 'long form' 587 protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be 588 zero on transmit and ignored on receive. The ar$pro.type field 589 itself identifies the protocol being referred to. This is termed 590 the 'short form' protocol ID. 592 In all cases, where a protocol has an assigned number in the 593 ar$pro.type space (excluding 0x0080) the short form MUST be used 594 when transmitting NHRP messages; i.e., if Ethertype or NLPID 595 codings exist then they are used on transmit rather than the 596 ethertype. If both Ethertype and NLPID codings exist then when 597 transmitting NHRP messages, the Ethertype coding MUST be used (this 598 is consistent with RFC 1483 coding). So, for example, the 599 following codings exist for IP: 601 SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00 602 NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00 603 Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00 605 and thus, since the Ethertype coding exists, it is used in 606 preference. 608 ar$hopcnt 609 The Hop count indicates the maximum number of NHSs that an NHRP 610 packet is allowed to traverse before being discarded. This field 611 is used in a similar fashion to the way that a TTL is used in an IP 612 packet and should be set accordingly. Each NHS decrements the TTL 613 as the NHRP packet transits the NHS on the way to the next hop 614 along the routed path to the destination. If an NHS receives an 615 NHRP packet which it would normally forward to a next hop and that 616 packet contains an ar$hopcnt set to zero then the NHS sends an 617 error indication message back to the source protocol address 618 stating that the hop count has been exceeded (see Section 5.2.7) 619 and the NHS drops the packet in error; however, an error 620 indication is never sent as a result of receiving an error 621 indication. When a responding NHS replies to an NHRP request, that 622 NHS places a value in ar$hopcnt as if it were sending a request of 623 its own. 625 ar$pktsz 626 The total length of the NHRP packet, in octets (excluding link 627 layer encapsulation). 629 ar$chksum 630 The standard IP checksum over the entire NHRP packet (starting with 631 the fixed header). If only the hop count field is changed, the 632 checksum is adjusted without full recomputation. The checksum is 633 completely recomputed when other header fields are changed. 635 ar$extoff 636 This field identifies the existence and location of NHRP 637 extensions. If this field is 0 then no extensions exist otherwise 638 this field represents the offset from the beginning of the NHRP 639 packet (i.e., starting from the ar$afn field) of the first 640 extension. 642 ar$op.version 643 This field indicates what version of generic address mapping and 644 management protocol is represented by this message. 646 0 MARS protocol [11]. 647 1 NHRP as defined in this document. 648 0x02 - 0xEF Reserved for future use by the IETF. 649 0xF0 - 0xFE Allocated for use by the ATM Forum. 650 0xFF Experimental/Local use. 652 ar$op.type 653 When ar$op.version == 1, this is the NHRP packet type: NHRP 654 Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration 655 Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP 656 Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet 657 Types in the range 128 to 255 are reserved for research or use in 658 other protocol development and will be administered by IANA. 660 ar$shtl 661 Type & length of source NBMA address interpreted in the context of 662 the 'address family number'[6] indicated by ar$afn. See below for 663 more details. 665 ar$sstl 666 Type & length of source NBMA subaddress interpreted in the context 667 of the 'address family number'[6] indicated by ar$afn. When an 668 NBMA technology has no concept of a subaddress, the subaddress 669 length is always coded ar$sstl = 0 and no storage is allocated for 670 the subaddress in the appropriate mandatory part. See below for 671 more details. 673 Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr 674 T/L) and subnetwork layer subaddresses type/length fields (e.g., 675 ar$sstl, Cli SAddr T/L) are coded as follows: 677 7 6 5 4 3 2 1 0 678 +-+-+-+-+-+-+-+-+ 679 |0|x| length | 680 +-+-+-+-+-+-+-+-+ 682 The most significant bit is reserved and MUST be set to zero. The 683 second most significant bit (x) is a flag indicating whether the 684 address being referred to is in: 686 - NSAP format (x = 0). 687 - Native E.164 format (x = 1). 689 For NBMA technologies that use neither NSAP nor E.164 format 690 addresses, x = 0 SHALL be used to indicate the native form for the 691 particular NBMA technology. 693 If the NBMA network is ATM and a subaddress (e.g., Source NBMA 694 SubAddress, Client NBMA SubAddress) is to be included in any part of 695 the NHRP packet then ar$afn MUST be set to 0x000F; further, the 696 subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr 697 T/L) and subnetwork layer subaddress type/length fields (e.g., 698 ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA 699 network is ATM and no subaddress field is to be included in any part 700 of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 701 (E.164) accordingly. 703 The bottom 6 bits is an unsigned integer value indicating the length 704 of the associated NBMA address in octets. If this value is zero the 705 flag x is ignored. 707 5.2.0 Mandatory Part 709 The Mandatory Part of the NHRP packet contains the operation specific 710 information (e.g., NHRP Resolution Request/Reply, etc.) and variable 711 length data which is pertinent to the packet type. 713 5.2.0.1 Mandatory Part Format 715 Sections 5.2.1 through 5.2.6 have a very similar mandatory part. 716 This mandatory part includes a common header and zero or more Client 717 Information Entries (CIEs). Section 5.2.7 has a different format 718 which is specified in that section. 720 The common header looks like the following: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Src Proto Len | Dst Proto Len | Flags | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Request ID | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Source NBMA Address (variable length) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Source NBMA Subaddress (variable length) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Source Protocol Address (variable length) | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Destination Protocol Address (variable length) | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 And the CIEs have the following format: 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Code | Prefix Length | unused | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Maximum Transmission Unit | Holding Time | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Client NBMA Address (variable length) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Client NBMA Subaddress (variable length) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Client Protocol Address (variable length) | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 ..................... 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Code | Prefix Length | unused | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Maximum Transmission Unit | Holding Time | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Client NBMA Address (variable length) | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Client NBMA Subaddress (variable length) | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Client Protocol Address (variable length) | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 The meanings of the fields are as follows: 772 Src Proto Len 773 This field holds the length in octets of the Source Protocol 774 Address. 776 Dst Proto Len 777 This field holds the length in octets of the Destination Protocol 778 Address. 780 Flags 781 These flags are specific to the given message type and they are 782 explained in each section. 784 Request ID 785 A value which, when coupled with the address of the source, 786 provides a unique identifier for the information contained in a 787 "request" packet. This value is copied directly from an "request" 788 packet into the associated "reply". When a sender of a "request" 789 receives "reply", it will compare the Request ID and source address 790 information in the received "reply" against that found in its 791 outstanding "request" list. When a match is found then the 792 "request" is considered to be acknowledged. 794 The value is taken from a 32 bit counter that is incremented each 795 time a new "request" is transmitted. The same value MUST be used 796 when resending a "request", i.e., when a "reply" has not been 797 received for a "request" and a retry is sent after an appropriate 798 interval. 800 The NBMA address/subaddress form specified below allows combined 801 E.164/NSAPA form of NBMA addressing. For NBMA technologies without a 802 subaddress concept, the subaddress field is always ZERO length and 803 ar$sstl = 0. 805 Source NBMA Address 806 The Source NBMA address field is the address of the source station 807 which is sending the "request". If the field's length as specified 808 in ar$shtl is 0 then no storage is allocated for this address at 809 all. 811 Source NBMA SubAddress 812 The Source NBMA subaddress field is the address of the source 813 station which is sending the "request". If the field's length as 814 specified in ar$sstl is 0 then no storage is allocated for this 815 address at all. 817 For those NBMA technologies which have a notion of "Calling Party 818 Addresses", the Source NBMA Addresses above are the addresses used 819 when signaling for an SVC. 821 "Requests" and "indications" follow the routed path from Source 822 Protocol Address to the Destination Protocol Address. "Replies", on 823 the other hand, follow the routed path from the Destination Protocol 824 Address back to the Source Protocol Address with the following 825 exceptions: in the case of a NHRP Registration Reply and in the case 826 of an NHC initiated NHRP Purge Request, the packet is always returned 827 via a direct VC (see Sections 5.2.4 and 5.2.5). 829 Source Protocol Address 830 This is the protocol address of the station which is sending the 831 "request". This is also the protocol address of the station toward 832 which a "reply" packet is sent. 834 Destination Protocol Address 835 This is the protocol address of the station toward which a 836 "request" packet is sent. 838 Code 839 This field is message specific. See the relevant message sections 840 below. In general, this field is a NAK code; i.e., when the field 841 is 0 in a reply then the packet is acknowledging a request and if 842 it contains any other value the packet contains a negative 843 acknowledgment. 845 Prefix Length 846 This field is message specific. See the relevant message sections 847 below. In general, however, this fields is used to indicate that 848 the information carried in an NHRP message pertains to an 849 equivalence class of internetwork layer addresses rather than just 850 a single internetwork layer address specified. All internetwork 851 layer addresses that match the first "Prefix Length" bit positions 852 for the specific internetwork layer address are included in the 853 equivalence class. If this field is set to 0x00 then this field 854 MUST be ignored and no equivalence information is assumed (note 855 that 0x00 is thus equivalent to 0xFF). 857 Maximum Transmission Unit 858 This field gives the maximum transmission unit for the relevant 859 client station. If this value is 0 then either the default MTU is 860 used or the MTU negotiated via signaling is used if such 861 negotiation is possible for the given NBMA. 863 Holding Time 864 The Holding Time field specifies the number of seconds for which 865 the Next Hop NBMA information specified in the CIE is considered to 866 be valid. Cached information SHALL be discarded when the holding 867 time expires. This field must be set to 0 on a NAK. 869 Cli Addr T/L 870 Type & length of next hop NBMA address specified in the CIE. This 871 field is interpreted in the context of the 'address family 872 number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM). 874 Cli SAddr T/L 875 Type & length of next hop NBMA subaddress specified in the CIE. 876 This field is interpreted in the context of the 'address family 877 number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes 878 the address an E.164 and the subaddress an ATM Forum NSAP address). 879 When an NBMA technology has no concept of a subaddress, the 880 subaddress is always null with a length of 0. When the address 881 length is specified as 0 no storage is allocated for the address. 883 Cli Proto Len 884 This field holds the length in octets of the Client Protocol 885 Address specified in the CIE. 887 Preference 888 This field specifies the preference for use of the specific CIE 889 relative to other CIEs. Higher values indicate higher preference. 890 Action taken when multiple CIEs have equal or highest preference 891 value is a local matter. 893 Client NBMA Address 894 This is the client's NBMA address. 896 Client NBMA SubAddress 897 This is the client's NBMA subaddress. 899 Client Protocol Address 900 This is the client's internetworking layer address specified. 902 Note that an NHS may cache source address binding information from an 903 NHRP Resolution Request if and only if the conditions described in 904 Section 6.2 are met for the NHS. In all other cases, source address 905 binding information appearing in an NHRP message MUST NOT be cached. 907 5.2.1 NHRP Resolution Request 909 The NHRP Resolution Request packet has a Type code of 1. Its 910 mandatory part is coded as described in Section 5.2.0.1 and the 911 message specific meanings of the fields are as follows: 913 Flags - The flags field is coded as follows: 915 0 1 916 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 |Q|A|D|U|S| unused | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Q 922 Set if the station sending the NHRP Resolution Request is a 923 router; clear if the it is a host. 925 A 926 This bit is set in a NHRP Resolution Request if only 927 authoritative next hop information is desired and is clear 928 otherwise. See the NHRP Resolution Reply section below for 929 further details on the "A" bit and its usage. 931 D 932 Unused (clear on transmit) 934 U 935 This is the Uniqueness bit. This bit aids in duplicate address 936 detection. When this bit is set in an NHRP Resolution Request 937 and one or more entries exist in the NHS cache which meet the 938 requirements of the NHRP Resolution Request then only the CIE in 939 the NHS's cache with this bit set will be returned. Note that 940 even if this bit was set at registration time, there may still be 941 multiple CIEs that might fulfill the NHRP Resolution Request 942 because an entire subnet can be registered through use of the 943 Prefix Length in the CIE and the address of interest might be 944 within such a subnet. If the "uniqueness" bit is set and the 945 responding NHS has one or more cache entries which match the 946 request but no such cache entry has the "uniqueness" bit set, 947 then the NHRP Resolution Reply returns with a NAK code of "13 - 948 Binding Exists But Is Not Unique" and no CIE is included. If a 949 client wishes to receive non- unique Next Hop Entries, then 950 the client must have the "uniqueness" bit set to zero in its NHRP 951 Resolution Request. Note that when this bit is set in an NHRP 952 Registration Request, only a single CIE may be specified in the 953 NHRP Registration Request and that CIE must have the Prefix 954 Length field set to 0xFF. 956 S 957 Set if the binding between the Source Protocol Address and the 958 Source NBMA information in the NHRP Resolution Request is 959 guaranteed to be stable and accurate (e.g., these addresses are 960 those of an ingress router which is connected to an ethernet stub 961 network or the NHC is an NBMA attached host). 963 Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP 964 Resolution Request. If one is specified then that entry carries the 965 pertinent information for the client sourcing the NHRP Resolution 966 Request. Usage of the CIE in the NHRP Resolution Request is 967 described below: 969 Prefix Length 970 If a CIE is specified in the NHRP Resolution Request then the 971 Prefix Length field may be used to qualify the widest acceptable 972 prefix which may be used to satisfy the NHRP Resolution Request. 973 In the case of NHRP Resolution Request/Reply, the Prefix Length 974 specifies the equivalence class of addresses which match the 975 first "Prefix Length" bit positions of the Destination Protocol 976 Address. If the "U" bit is set in the common header then this 977 field MUST be set to 0xFF. 979 Maximum Transmission Unit 980 This field gives the maximum transmission unit for the source 981 station. A possible use of this field in the NHRP Resolution 982 Request packet is for the NHRP Resolution Requester to ask for a 983 target MTU. In lieu of that usage, the CIE must be omitted. 985 Holding Time 986 The Holding Time specified in the one CIE permitted to be 987 included in an NHRP Resolution Request is the amount of time 988 which the source address binding information in the NHRP 989 Resolution Request is permitted to cached by transit and 990 responding NHSs. Note that this field may only have a non-zero 991 value if the S bit is set. 993 All other fields in the CIE MUST be ignored and SHOULD be set to 0. 995 The Destination Protocol Address in the common header of the 996 Mandatory Part of this message contains the protocol address of the 997 station for which resolution is desired. An NHC MUST send the NHRP 998 Resolution Request directly to one of its serving NHSs (see Section 3 999 for more information). 1001 5.2.2 NHRP Resolution Reply 1003 The NHRP Resolution Reply packet has a Type code of 2. CIEs 1004 correspond to Next Hop Entries in an NHS's cache which match the 1005 criteria in the NHRP Resolution Request. Its mandatory part is coded 1006 as described in Section 5.2.0.1. The message specific meanings of 1007 the fields are as follows: 1009 Flags - The flags field is coded as follows: 1011 0 1 1012 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 |Q|A|D|U|S| unused | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 Q 1018 Copied from the NHRP Resolution Request. Set if the NHRP 1019 Resolution Requester is a router; clear if it is a host. 1021 A 1022 Set if the next hop CIE in the NHRP Resolution Reply is 1023 authoritative; clear if the NHRP Resolution Reply is non- 1024 authoritative. 1026 When an NHS receives a NHRP Resolution Request for authoritative 1027 information for which it is the authoritative source, it MUST 1028 respond with a NHRP Resolution Reply containing all and only 1029 those next hop CIEs which are contained in the NHS's cache which 1030 both match the criteria of the NHRP Resolution Request and are 1031 authoritative cache entries. An NHS is an authoritative source 1032 for a NHRP Resolution Request if the information in the NHS's 1033 cache matches the NHRP Resolution Request criteria and that 1034 information was obtained through a NHRP Registration Request or 1035 through synchronization with an NHS which obtained this 1036 information through a NHRP Registration Request. An 1037 authoritative cache entry is one which is obtained through a NHRP 1038 Registration Request or through synchronization with an NHS which 1039 obtained this information through a NHRP Registration Request. 1041 An NHS obtains non-authoritative CIEs through promiscuous 1042 listening to NHRP packets other than NHRP Registrations which are 1043 directed at it. A NHRP Resolution Request which indicates a 1044 request for non-authoritative information should cause a NHRP 1045 Resolution Reply which contains all entries in the replying NHS's 1046 cache (i.e., both authoritative and non-authoritative) which 1047 match the criteria specified in the request. 1049 D 1050 Set if the association between destination and the associate next 1051 hop information included in all CIEs of the NHRP Resolution Reply 1052 is guaranteed to be stable for the lifetime of the information 1053 (the holding time). This is the case if the Next Hop protocol 1054 address in a CIE identifies the destination (though it may be 1055 different in value than the Destination address if the 1056 destination system has multiple addresses) or if the destination 1057 is not connected directly to the NBMA subnetwork but the egress 1058 router to that destination is guaranteed to be stable (such as 1059 when the destination is immediately adjacent to the egress router 1060 through a non-NBMA interface). 1062 U 1063 This is the Uniqueness bit. See the NHRP Resolution Request 1064 section above for details. When this bit is set only, only one 1065 CIE is included since only one unique binding should exist in an 1066 NHS's cache. 1068 S 1069 Copied from NHRP Resolution Request message. 1071 One or more CIEs are specified in the NHRP Resolution Reply. Each CIE 1072 contains NHRP next hop information which the responding NHS has 1073 cached and which matches the parameters specified in the NHRP 1074 Resolution Request. If no match is found by the NHS issuing the NHRP 1075 Resolution Reply then a single CIE is enclosed with the a CIE Code 1076 set appropriately (see below) and all other fields MUST be ignored 1077 and SHOULD be set to 0. In order to facilitate the use of NHRP by 1078 minimal client implementations, the first CIE MUST contain the next 1079 hop with the highest preference value so that such an implementation 1080 need parse only a single CIE. 1082 Code 1083 If this field is set to zero then this packet contains a 1084 positively acknowledged NHRP Resolution Reply. If this field 1085 contains any other value then this message contains an NHRP 1086 Resolution Reply NAK which means that an appropriate 1087 internetworking layer to NBMA address binding was not available 1088 in the responding NHS's cache. If NHRP Resolution Reply contains 1089 a Client Information Entry with a NAK Code other than 0 then it 1090 MUST NOT contain any other CIE. Currently defined NAK Codes are 1091 as follows: 1093 4 - Administratively Prohibited 1095 An NHS may refuse an NHRP Resolution Request attempt for 1096 administrative reasons (due to policy constraints or routing 1097 state). If so, the NHS MUST send an NHRP Resolution Reply 1098 which contains a NAK code of 4. 1100 5 - Insufficient Resources 1102 If an NHS cannot serve a station due to a lack of resources 1103 (e.g., can't store sufficient information to send a purge if 1104 routing changes), the NHS MUST reply with a NAKed NHRP 1105 Resolution Reply which contains a NAK code of 5. 1107 12 - No Internetworking Layer Address to NBMA Address Binding 1108 Exists 1110 This code states that there were absolutely no internetworking 1111 layer address to NBMA address bindings found in the responding 1112 NHS's cache. 1114 13 - Binding Exists But Is Not Unique 1116 This code states that there were one or more internetworking 1117 layer address to NBMA address bindings found in the responding 1118 NHS's cache, however none of them had the uniqueness bit set. 1120 Prefix Length 1121 In the case of NHRP Resolution Reply, the Prefix Length specifies 1122 the equivalence class of addresses which match the first "Prefix 1123 Length" bit positions of the Destination Protocol Address. 1125 Holding Time 1126 The Holding Time specified in a CIE of an NHRP Resolution Reply 1127 is the amount of time remaining before the expiration of the 1128 client information which is cached at the replying NHS. It is 1129 not the value which was registered by the client. 1131 The remainder of the fields for the CIE for each next hop are 1132 filled out as they were defined when the next hop was registered 1133 with the responding NHS (or one of the responding NHS's 1134 synchronized servers) via the NHRP Registration Request. 1136 Load-splitting may be performed when more than one Client Information 1137 Entry is returned to a requester when equal preference values are 1138 specified. Also, the alternative addresses may be used in case of 1139 connectivity failure in the NBMA subnetwork (such as a failed call 1140 attempt in connection-oriented NBMA subnetworks). 1142 Any extensions present in the NHRP Resolution Request packet MUST be 1143 present in the NHRP Resolution Reply even if the extension is non- 1144 Compulsory. 1146 If an unsolicited NHRP Resolution Reply packet is received, an Error 1147 Indication of type Invalid NHRP Resolution Reply Received SHOULD be 1148 sent in response. 1150 When an NHS that serves a given NHC receives an NHRP Resolution Reply 1151 destined for that NHC then the NHS must MUST send the NHRP Resolution 1152 Reply directly to the NHC (see Section 3). 1154 5.2.3 NHRP Registration Request 1156 The NHRP Registration Request is sent from a station to an NHS to 1157 notify the NHS of the station's NBMA information. It has a Type code 1158 of 3. Each CIE corresponds to Next Hop information which is to be 1159 cached at an NHS. The mandatory part of an NHRP Registration Request 1160 is coded as described in Section 5.2.0.1. The message specific 1161 meanings of the fields are as follows: 1163 Flags - The flags field is coded as follows: 1165 0 1 1166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 |U| unused | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 U 1172 This is the Uniqueness bit. When set in an NHRP Registration 1173 Request, this bit indicates that the registration of the protocol 1174 address is unique within the confines of the set of synchronized 1175 NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC 1176 cache. Any attempt to register a binding between the protocol 1177 address and an NBMA address when this bit is set MUST be rejected 1178 with a Code of "14 - Unique Internetworking Layer Address Already 1179 Registered" if the replying NHS already has a cache entry for the 1180 protocol address and the cache entry has the "uniqueness" bit 1181 set. A registration of a CIE's information is rejected when the 1182 CIE is returned with the Code field set to anything other than 1183 0x00. See the description of the uniqueness bit in NHRP 1184 Resolution Request section above for further details. When this 1185 bit is set only, only one CIE MAY be included in the NHRP 1186 Registration Request. 1188 Request ID 1189 The request ID has the same meaning as described in Section 1190 5.2.0.1. However, the request ID for NHRP Registrations which is 1191 maintained at each client MUST be kept in non-volatile memory so 1192 that when a client crashes and reregisters there will be no 1193 inconsistency in the NHS's database. In order to reduce the 1194 overhead associated with updating non-volatile memory, the actual 1195 updating need not be done with every increment of the Request ID 1196 but could be done, for example, every 50 or 100 increments. In 1197 this scenario, when a client crashes and reregisters it knows to 1198 add 100 to the value of the Request ID in the non-volatile memory 1199 before using the Request ID for subsequent registrations. 1201 One or more CIEs are specified in the NHRP Registration Request. 1202 Each CIE contains next hop information which a client is attempting 1203 to register with its servers. Generally, all fields in CIEs enclosed 1204 in NHRP Registration Requests are coded as described in Section 1205 5.2.0.1. However, if a station is only registering itself with the 1206 NHRP Registration Request then it MAY code the Cli Addr T/L, Cli 1207 SAddr T/L, and Cli Proto Len as zero which signifies that the client 1208 address information is to be taken from the source information in the 1209 common header (see Section 5.2.0.1). Below, further clarification is 1210 given for some fields in a CIE in the context of a NHRP Registration 1211 Request. 1213 Code 1214 This field is set to 0x00 in NHRP Registration Requests. 1216 Prefix Length 1218 This field may be used in a NHRP Registration Request to register 1219 equivalence information for the Client Protocol Address specified 1220 in the CIE of an NHRP Registration Request In the case of NHRP 1221 Registration Request, the Prefix Length specifies the equivalence 1222 class of addresses which match the first "Prefix Length" bit 1223 positions of the Client Protocol Address. If the "U" bit is set 1224 in the common header then this field MUST be set to 0xFF. 1226 The NHRP Registration Request is used to register an NHC's NHRP 1227 information with its NHSs. If an NHC is configured with the protocol 1228 address of a serving NHS then the NHC may place the NHS's protocol 1229 address in the Destination Protocol Address field of the NHRP 1230 Registration Request common header otherwise the NHC must place its 1231 own protocol address in the Destination Protocol Address field. 1233 When an NHS receives an NHRP Registration Request which has the 1234 Destination Protocol Address field set to an address which belongs to 1235 a LIS/LAG for which the NHS is serving then if the Destination 1236 Protocol Address field is equal to the Source Protocol Address field 1237 (which would happen if the NHC put its protocol address in the 1238 Destination Protocol Address) or the Destination Protocol Address 1239 field is equal to the protocol address of the NHS then the NHS 1240 processes the NHRP Registration Request after doing appropriate error 1241 checking (including any applicable policy checking). 1243 When an NHS receives an NHRP Registration Request which has the 1244 Destination Protocol Address field set to an address which does not 1245 belong to a LIS/LAG for which the NHS is serving then the NHS 1246 forwards the packet down the routed path toward the appropriate 1247 LIS/LAG. 1249 When an NHS receives an NHRP Registration Request which has the 1250 Destination Protocol Address field set to an address which belongs to 1251 a LIS/LAG for which the NHS is serving then if the Destination 1252 Protocol Address field does not equal the Source Protocol Address 1253 field and the Destination Protocol Address field does not equal the 1254 protocol address of the NHS then the NHS forwards the message to the 1255 appropriate NHS within the LIS/LAG as specified by Destination 1256 Protocol Address field. 1258 It is possible that a misconfigured station will attempt to register 1259 with the wrong NHS (i.e., one that cannot serve it due to policy 1260 constraints or routing state). If this is the case, the NHS MUST 1261 reply with a NAK-ed Registration Reply of type Can't Serve This 1262 Address. 1264 If an NHS cannot serve a station due to a lack of resources, the NHS 1265 MUST reply with a NAK-ed Registration Reply of type Registration 1266 Overflow. 1268 In order to keep the registration entry from being discarded, the 1269 station MUST re-send the NHRP Registration Request packet often 1270 enough to refresh the registration, even in the face of occasional 1271 packet loss. It is recommended that the NHRP Registration Request 1272 packet be sent at an interval equal to one-third of the Holding Time 1273 specified therein. 1275 5.2.4 NHRP Registration Reply 1277 The NHRP Registration Reply is sent by an NHS to a client in response 1278 to that client's NHRP Registration Request. If the Code field of a 1279 CIE in the NHRP Registration Reply has anything other than 0 zero in 1280 it then the NHRP Registration Reply is a NAK otherwise the reply is 1281 an ACK. The NHRP Registration Reply has a Type code of 4. 1283 An NHRP Registration Reply is formed from an NHRP Registration 1284 Request by changing the type code to 4, updating the CIE Code field, 1285 and filling in the appropriate extensions if they exist. The message 1286 specific meanings of the fields are as follows: 1288 Attempts to register the information in the CIEs of an NHRP 1289 Registration Request may fail for various reasons. If this is the 1290 case then each failed attempt to register the information in a CIE of 1291 an NHRP Registration Request is logged in the associated NHRP 1292 Registration Reply by setting the CIE Code field to the appropriate 1293 error code as shown below: 1295 CIE Code 1297 0 - Successful Registration 1299 The information in the CIE was successfully registered with the 1300 NHS. 1302 4 - Administratively Prohibited 1304 An NHS may refuse an NHRP Registration Request attempt for 1305 administrative reasons (due to policy constraints or routing 1306 state). If so, the NHS MUST send an NHRP Registration Reply 1307 which contains a NAK code of 4. 1309 5 - Insufficient Resources 1311 If an NHS cannot serve a station due to a lack of resources, 1312 the NHS MUST reply with a NAKed NHRP Registration Reply which 1313 contains a NAK code of 5. 1315 14 - Unique Internetworking Layer Address Already Registered 1316 If a client tries to register a protocol address to NBMA 1317 address binding with the uniqueness bit on and the protocol 1318 address already exists in the NHS's cache then if that cache 1319 entry also has the uniqueness bit on then this NAK Code is 1320 returned in the CIE in the NHRP Registration Reply. 1322 Due to the possible existence of asymmetric routing, an NHRP 1323 Registration Reply may not be able to merely follow the routed path 1324 back to the source protocol address specified in the common header of 1325 the NHRP Registration Reply. As a result, there MUST exist a direct 1326 NBMA level connection between the NHC and its NHS on which to send 1327 the NHRP Registration Reply before NHRP Registration Reply may be 1328 returned to the NHC. If such a connection does not exist then the 1329 NHS must setup such a connection to the NHC by using the source NBMA 1330 information supplied in the common header of the NHRP Registration 1331 Request. 1333 5.2.5 NHRP Purge Request 1335 The NHRP Purge Request packet is sent in order to invalidate cached 1336 information in a station. The NHRP Purge Request packet has a type 1337 code of 5. The mandatory part of an NHRP Purge Request is coded as 1338 described in Section 5.2.0.1. The message specific meanings of the 1339 fields are as follows: 1341 Flags - The flags field is coded as follows: 1343 0 1 1344 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 |N| unused | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 N 1350 When set, this bit tells the receiver of the NHRP Purge Request 1351 that the requester does not expect to receive an NHRP Purge 1352 Reply. If an unsolicited NHRP Purge Reply is received by a 1353 station where that station is identified in the Source Protocol 1354 Address of the packet then that packet must be ignored. 1356 One or more CIEs are specified in the NHRP Purge Request. Each CIE 1357 contains next hop information which is to be purged from an NHS/NHC 1358 cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests 1359 are coded as described in Section 5.2.0.1. Below, further 1360 clarification is given for some fields in a CIE in the context of a 1361 NHRP Purge Request. 1363 Code 1364 This field is set to 0x00 in NHRP Purge Requests. 1366 Prefix Length 1368 In the case of NHRP Purge Requests, the Prefix Length specifies 1369 the equivalence class of addresses which match the first "Prefix 1370 Length" bit positions of the Client Protocol Address specified in 1371 the CIE. All next hop information which contains a protocol 1372 address which matches an element of this equivalence class is to 1373 be purged from the receivers cache. 1375 The Maximum Transmission Unit and Preference fields of the CIE are 1376 coded as zero. The Holding Time should be coded as zero but there 1377 may be some utility in supplying a "short" holding time to be 1378 applied to the matching next hop information before that 1379 information would be purged; this usage is for further study. The 1380 Client Protocol Address field and the Cli Proto Len field MUST be 1381 filled in. The Client Protocol Address is filled in with the 1382 protocol address to be purged from the receiving station's cache 1383 while the Cli Proto Len is set the length of the purged client's 1384 protocol address. All remaining fields in the CIE MAY be set to 1385 zero although the client NBMA information (and associated length 1386 fields) MAY be specified to narrow the scope of the NHRP Purge 1387 Request if requester desires. However, the receiver of an NHRP 1388 Purge Request may choose to ignore the Client NBMA information if 1389 it is supplied. 1391 An NHRP Purge Request packet is sent from an NHS to a station to 1392 cause it to delete previously cached information. This is done when 1393 the information may be no longer valid (typically when the NHS has 1394 previously provided next hop information for a station that is not 1395 directly connected to the NBMA subnetwork, and the egress point to 1396 that station may have changed). 1398 An NHRP Purge Request packet may also be sent from an NHC to an NHS 1399 with which the NHC had previously registered. This allows for an NHC 1400 to invalidate its registration with NHRP before it would otherwise 1401 expire via the holding timer. If an NHC does not have knowledge of a 1402 protocol address of a serving NHS then the NHC must place its own 1403 protocol address in the Destination Protocol Address field and 1404 forward the packet along the routed path. Otherwise, the NHC must 1405 place the protocol address of a serving NHS in this field. 1407 Serving NHSs may need to send one or more new NHRP Purge Requests as 1408 a result of receiving a purge from one of their served NHCs since the 1409 NHS may have previously responded to NHRP Resolution Requests for 1410 that NHC's NBMA information. These purges are "new" in that they are 1411 sourced by the NHS and not the NHC; that is, for each NHC that 1412 previously sent a NHRP Resolution Request for the purged NHC NBMA 1413 information, an NHRP Purge Request is sent which contains the Source 1414 Protocol/NBMA Addresses of the NHS and the Destination Protocol 1415 Address of the NHC which previously sent an NHRP Resolution Request 1416 prior to the purge. 1418 The station sending the NHRP Purge Request MAY periodically 1419 retransmit the NHRP Purge Request until either NHRP Purge Request is 1420 acknowledged or until the holding time of the information being 1421 purged has expired. Retransmission strategies for NHRP Purge Requests 1422 are a local matter. 1424 When a station receives an NHRP Purge Request, it MUST discard any 1425 previously cached information that matches the information in the 1426 CIEs. 1428 An NHRP Purge Reply MUST be returned for the NHRP Purge Request even 1429 if the station does not have a matching cache entry assuming that the 1430 "N" bit is off in the NHRP Purge Request. 1432 If the station wishes to reestablish communication with the 1433 destination shortly after receiving an NHRP Purge Request, it should 1434 make an authoritative NHRP Resolution Request in order to avoid any 1435 stale cache entries that might be present in intermediate NHSs (See 1436 section 6.2.2.). It is recommended that authoritative NHRP 1437 Resolution Requests be made for the duration of the holding time of 1438 the old information. 1440 5.2.6 NHRP Purge Reply 1442 The NHRP Purge Reply packet is sent in order to assure the sender of 1443 an NHRP Purge Request that all cached information of the specified 1444 type has been purged from the station sending the reply. The NHRP 1445 Purge Reply has a type code of 6. 1447 An NHRP Purge Reply is formed from an NHRP Purge Request by merely 1448 changing the type code in the request to 6. The packet is then 1449 returned to the requester after filling in the appropriate extensions 1450 if they exist. 1452 5.2.7 NHRP Error Indication 1454 The NHRP Error Indication is used to convey error indications to the 1455 sender of an NHRP packet. It has a type code of 7. The Mandatory 1456 Part has the following format: 1458 0 1 2 3 1459 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 1460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 | Src Proto Len | Dst Proto Len | unused | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1463 | Error Code | Error Offset | 1464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 | Source NBMA Address (variable length) | 1466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1467 | Source NBMA Subaddress (variable length) | 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Source Protocol Address (variable length) | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Destination Protocol Address (variable length) | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Contents of NHRP Packet in error (variable length) | 1474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 Src Proto Len 1477 This field holds the length in octets of the Source Protocol 1478 Address. 1480 Dst Proto Len 1481 This field holds the length in octets of the Destination Protocol 1482 Address. 1484 Error Code 1485 An error code indicating the type of error detected, chosen from 1486 the following list: 1488 1 - Unrecognized Extension 1490 When the Compulsory bit of an extension in NHRP packet is set, 1491 the NHRP packet cannot be processed unless the extension has 1492 been processed. The responder MUST return an NHRP Error 1493 Indication of type Unrecognized Extension if it is incapable of 1494 processing the extension. However, if a transit NHS (one which 1495 is not going to generate a reply) detects an unrecognized 1496 extension, it SHALL ignore the extension. 1498 3 - NHRP Loop Detected 1500 A Loop Detected error is generated when it is determined that 1501 an NHRP packet is being forwarded in a loop. 1503 6 - Protocol Address Unreachable 1505 This error occurs when a packet it moving along the routed path 1506 and it reaches a point such that the protocol address of 1507 interest is not reachable. 1509 7 - Protocol Error 1511 A generic packet processing error has occurred (e.g., invalid 1512 version number, invalid protocol type, failed checksum, etc.) 1514 8 - NHRP SDU Size Exceeded 1516 If the SDU size of the NHRP packet exceeds the MTU size of the 1517 NBMA network then this error is returned. 1519 9 - Invalid Extension 1521 If an NHS finds an extension in a packet which is inappropriate 1522 for the packet type, an error is sent back to the sender with 1523 Invalid Extension as the code. 1525 10 - Invalid NHRP Resolution Reply Received 1527 If a client receives a NHRP Resolution Reply for a Next Hop 1528 Resolution Request which it believes it did not make then an 1529 error packet is sent to the station making the reply with an 1530 error code of Invalid Reply Received. 1532 11 - Authentication Failure 1534 If a received packet fails an authentication test then this 1535 error is returned. 1537 15 - Hop Count Exceeded 1539 The hop count which was specified in the Fixed Header of an 1540 NHRP message has been exceeded. 1542 Error Offset 1543 The offset in octets into the NHRP packet, starting at the NHRP 1544 Fixed Header, at which the error was detected. 1546 Source NBMA Address 1547 The Source NBMA address field is the address of the station which 1548 observed the error. 1550 Source NBMA SubAddress 1551 The Source NBMA subaddress field is the address of the station 1552 which observed the error. If the field's length as specified in 1553 ar$sstl is 0 then no storage is allocated for this address at all. 1555 Source Protocol Address 1556 This is the protocol address of the station which issued the Error 1557 packet. 1559 Destination Protocol Address 1560 This is the protocol address of the station which sent the packet 1561 which was found to be in error. 1563 An NHRP Error Indication packet SHALL NEVER be generated in response 1564 to another NHRP Error Indication packet. When an NHRP Error 1565 Indication packet is generated, the offending NHRP packet SHALL be 1566 discarded. In no case should more than one NHRP Error Indication 1567 packet be generated for a single NHRP packet. 1569 If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA 1570 and Source Protocol address fields of a transiting NHRP Error 1571 Indication packet then the NHS will quietly drop the packet and do 1572 nothing (this scenario would occur when the NHRP Error Indication 1573 packet was itself in a loop). 1575 Note that no extensions may be added to an NHRP Error Indication. 1577 5.3 Extensions Part 1579 The Extensions Part, if present, carries one or more extensions in 1580 {Type, Length, Value} triplets. 1582 Extensions have the following format: 1584 0 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 |C|u| Type | Length | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Value... | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 C 1593 "Compulsory." If clear, and the NHS does not recognize the type 1594 code, the extension may safely be ignored. If set, and the NHS 1595 does not recognize the type code, the NHRP "request" is considered 1596 to be in error. (See below for details.) 1598 u 1599 Unused and must be set to zero. 1601 Type 1602 The extension type code (see below). The extension type is not 1603 qualified by the Compulsory bit, but is orthogonal to it. 1605 Length 1606 The length in octets of the value (not including the Type and 1607 Length fields; a null extension will have only an extension header 1608 and a length of zero). 1610 When extensions exist, the extensions list is terminated by the Null 1611 TLV, having Type = 0 and Length = 0. 1613 Extensions may occur in any order (see Section 5.3.4 for the 1614 exception), but any particular extension type may occur only once in 1615 an NHRP packet with the exception of the Vendor Private extension. 1616 The vendor-private extension may occur multiple times in a packet in 1617 order to allow for extensions which do not share the same vendor ID 1618 to be represented. It is RECOMMENDED that a given vendor include no 1619 more than one Vendor Private Extension. 1621 An NHS MUST NOT change the order of extensions. That is, the order 1622 of extensions placed in an NHRP packet by an NHC (or by an NHS when 1623 an NHS sources a packet) MUST be preserved as the packet moves 1624 between NHSs. Minimal NHC implementations MUST only recognize, but 1625 not necessarily parse, the Vendor Private extension and the End Of 1626 Extensions extension. Extensions are only present in a "reply" if 1627 they were present in the corresponding "request" with the exception 1628 of Vendor Private extensions. The previous statement is not intended 1629 to preclude the creation of NHS-only extensions which might be added 1630 to and removed from NHRP packets by the same NHS; such extensions 1631 MUST not be propagated to NHCs. 1633 The Compulsory bit provides for a means to add to the extension set. 1634 If the bit is set, the NHRP message cannot be properly processed by 1635 the station responding to the message (e.g., the station that would 1636 issue a NHRP Resolution Reply in response to a NHRP Resolution 1637 Request) without processing the extension. As a result, the 1638 responder MUST return an NHRP Error Indication of type Unrecognized 1639 Extension. If the Compulsory bit is clear then the extension can be 1640 safely ignored; however, if an ignored extension is in a "request" 1641 then it MUST be returned, unchanged, in the corresponding "reply" 1642 packet type. 1644 If a transit NHS (one which is not going to generate a "reply") 1645 detects an unrecognized extension, it SHALL ignore the extension. If 1646 the Compulsory bit is set, the transit NHS MUST NOT cache the 1647 information contained in the packet and MUST NOT identify itself as 1648 an egress router (in the Forward Record or Reverse Record 1649 extensions). Effectively, this means, if a transit NHS encounters an 1650 extension which it cannot process and which has the Compulsory bit 1651 set then that NHS MUST NOT participate in any way in the protocol 1652 exchange other than acting as a forwarding agent. 1654 The NHRP extension Type space is subdivided to encourage use outside 1655 the IETF. 1657 0x0000 - 0x0FFF Reserved for NHRP. 1658 0x1000 - 0x11FF Allocated to the ATM Forum. 1659 0x1200 - 0x37FF Reserved for the IETF. 1660 0x3800 - 0x3FFF Experimental use. 1662 IANA will administer the ranges reserved for the IETF. Values in the 1663 'Experimental use' range have only local sigificance. 1665 5.3.0 The End Of Extensions 1667 Compulsory = 1 1668 Type = 0 1669 Length = 0 1671 When extensions exist, the extensions list is terminated by the End 1672 Of Extensions/Null TLV. 1674 5.3.1 Responder Address Extension 1676 Compulsory = 1 1677 Type = 3 1678 Length = variable 1680 This extension is used to determine the address of the NHRP 1681 responder; i.e., the entity that generates the appropriate "reply" 1682 packet for a given "request" packet. In the case of an NHRP 1683 Resolution Request, the station responding may be different (in the 1684 case of cached replies) than the system identified in the Next Hop 1685 field of the NHRP Resolution Reply. Further, this extension may aid 1686 in detecting loops in the NHRP forwarding path. 1688 This extension uses a single CIE with the extension specific meanings 1689 of the fields set as follows: 1691 The Prefix Length fields MUST be set to 0 and ignored. 1693 CIE Code 1694 5 - Insufficient Resources 1695 If the responder to an NHRP Resolution Request is an egress point 1696 for the target of the address resolution request (i.e., it is one 1697 of the stations identified in the list of CIEs in an NHRP 1698 Resolution Reply) and the Responder Address extension is included 1699 in the NHRP Resolution Request and insufficient resources to 1700 setup a cut-through VC exist at the responder then the Code field 1701 of the Responder Address Extension is set to 5 in order to tell 1702 the client that a VC setup attempt would in all likelihood be 1703 rejected; otherwise this field MUST be coded as a zero. NHCs MAY 1704 use this field to influence whether they attempt to setup a cut- 1705 through to the egress router. 1707 Maximum Transmission Unit 1708 This field gives the maximum transmission unit preferred by the 1709 responder. If this value is 0 then either the default MTU is used 1710 or the MTU negotiated via signaling is used if such negotiation is 1711 possible for the given NBMA. 1713 Holding Time 1714 The Holding Time field specifies the number of seconds for which 1715 the NBMA information of the responser is considered to be valid. 1716 Cached information SHALL be discarded when the holding time 1717 expires. 1719 "Client Address" information is actually "Responder Address" 1720 information for this extension. Thus, for example, Cli Addr T/L is 1721 the responder NBMA address type and length field. 1723 If a "requester" desires this information, the "requester" SHALL 1724 include this extension with a value of zero. Note that this implies 1725 that no storage is allocated for the Holding Time and Type/Length 1726 fields until the "Value" portion of the extension is filled out. 1728 If an NHS is generating a "reply" packet in response to a "request" 1729 containing this extension, the NHS SHALL include this extension, 1730 containing its protocol address in the "reply". If an NHS has more 1731 than one protocol address, it SHALL use the same protocol address 1732 consistently in all of the Responder Address, Forward Transit NHS 1733 Record, and Reverse Transit NHS Record extensions. The choice of 1734 which of several protocol address to include in this extension is a 1735 local matter. 1737 If an NHRP Resolution Reply packet being forwarded by an NHS contains 1738 a protocol address of that NHS in the Responder Address Extension 1739 then that NHS SHALL generate an NHRP Error Indication of type "NHRP 1740 Loop Detected" and discard the NHRP Resolution Reply. 1742 If an NHRP Resolution Reply packet is being returned by an 1743 intermediate NHS based on cached data, it SHALL place its own address 1744 in this extension (differentiating it from the address in the Next 1745 Hop field). 1747 5.3.2 NHRP Forward Transit NHS Record Extension 1749 Compulsory = 1 1750 Type = 4 1751 Length = variable 1753 The NHRP Forward Transit NHS record contains a list of transit NHSs 1754 through which a "request" has traversed. Each NHS SHALL append to 1755 the extension a Forward Transit NHS element (as specified below) 1756 containing its Protocol address The extension length field and the 1757 ar$chksum fields SHALL be adjusted appropriately. 1759 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1760 this extension. 1762 In addition, NHSs that are willing to act as egress routers for 1763 packets from the source to the destination SHALL include information 1764 about their NBMA Address. 1766 This extension uses a single CIE with the extension specific meanings 1767 of the fields set as follows: 1769 The Prefix Length fields MUST be set to 0 and ignored. 1771 CIE Code 1772 5 - Insufficient Resources 1773 If an NHRP Resolution Request contains an NHRP Forward Transit 1774 NHS Record Extension and insufficient resources to setup a cut- 1775 through VC exist at the current transit NHS then the CIE Code 1776 field for NHRP Forward Transit NHS Record Extension is set to 5 1777 in order to tell the client that a VC setup attempt would in all 1778 likelihood be rejected; otherwise this field MUST be coded as a 1779 zero. NHCs MAY use this field to influence whether they attempt 1780 to setup a cut-through as described in Section 2.2. Note that 1781 the NHRP Reverse Transit NHS Record Extension MUST always have 1782 this field set to zero. 1784 Maximum Transmission Unit 1785 This field gives the maximum transmission unit preferred by the 1786 transit NHS. If this value is 0 then either the default MTU is 1787 used or the MTU negotiated via signaling is used if such 1788 negotiation is possible for the given NBMA. 1790 Holding Time 1791 The Holding Time field specifies the number of seconds for which 1792 the NBMA information of the transit NHS is considered to be valid. 1793 Cached information SHALL be discarded when the holding time 1794 expires. 1796 "Client Address" information is actually "Forward Transit NHS 1797 Address" information for this extension. Thus, for example, Cli Addr 1798 T/L is the transit NHS NBMA address type and length field. 1800 If a "requester" wishes to obtain this information, it SHALL include 1801 this extension with a length of zero. Note that this implies that no 1802 storage is allocated for the Holding Time and Type/Length fields 1803 until the "Value" portion of the extension is filled out. 1805 If an NHS has more than one Protocol address, it SHALL use the same 1806 Protocol address consistently in all of the Responder Address, 1807 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1808 which of several Protocol addresses to include in this extension is a 1809 local matter. 1811 If a "request" that is being forwarded by an NHS contains the 1812 Protocol Address of that NHS in one of the Forward Transit NHS 1813 elements then the NHS SHALL generate an NHRP Error Indication of type 1814 "NHRP Loop Detected" and discard the "request". 1816 5.3.3 NHRP Reverse Transit NHS Record Extension 1818 Compulsory = 1 1819 Type = 5 1820 Length = variable 1822 The NHRP Reverse Transit NHS record contains a list of transit NHSs 1823 through which a "reply" has traversed. Each NHS SHALL append a 1824 Reverse Transit NHS element (as specified below) containing its 1825 Protocol address to this extension. The extension length field and 1826 ar$chksum SHALL be adjusted appropriately. 1828 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1829 this extension. 1831 In addition, NHSs that are willing to act as egress routers for 1832 packets from the source to the destination SHALL include information 1833 about their NBMA Address. 1835 This extension uses a single CIE with the extension specific meanings 1836 of the fields set as follows: 1838 The CIE Code and Prefix Length fields MUST be set to 0 and ignored. 1840 Maximum Transmission Unit 1841 This field gives the maximum transmission unit preferred by the 1842 transit NHS. If this value is 0 then either the default MTU is 1843 used or the MTU negotiated via signaling is used if such 1844 negotiation is possible for the given NBMA. 1846 Holding Time 1847 The Holding Time field specifies the number of seconds for which 1848 the NBMA information of the transit NHS is considered to be valid. 1849 Cached information SHALL be discarded when the holding time 1850 expires. 1852 "Client Address" information is actually "Reverse Transit NHS 1853 Address" information for this extension. Thus, for example, Cli Addr 1854 T/L is the transit NHS NBMA address type and length field. 1856 If a "requester" wishes to obtain this information, it SHALL include 1857 this extension with a length of zero. Note that this implies that no 1858 storage is allocated for the Holding Time and Type/Length fields 1859 until the "Value" portion of the extension is filled out. 1861 If an NHS has more than one Protocol address, it SHALL use the same 1862 Protocol address consistently in all of the Responder Address, 1863 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1864 which of several Protocol addresses to include in this extension is a 1865 local matter. 1867 If a "reply" that is being forwarded by an NHS contains the Protocol 1868 Address of that NHS in one of the Reverse Transit NHS elements then 1869 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop 1870 Detected" and discard the "reply". 1872 Note that this information may be cached at intermediate NHSs; if 1873 so, the cached value SHALL be used when generating a reply. 1875 5.3.4 NHRP Authentication Extension 1877 Compulsory = 1 1878 Type = 7 1879 Length = variable 1881 The NHRP Authentication Extension is carried in NHRP packets to 1882 convey authentication information between NHRP speakers. The 1883 Authentication Extension may be included in any NHRP "request" or 1884 "reply" only. 1886 Except in the case of an NHRP Registration Request/Reply 1887 Authentication is done pairwise on an NHRP hop-by-hop basis; i.e., 1888 the authentication extension is regenerated at each hop. In the case 1889 of an NHRP Registration Request/Reply, the Authentication is checked 1890 on an end-to-end basis rather than hop-by-hop. If a received packet 1891 fails the authentication test, the station SHALL generate an Error 1892 Indication of type "Authentication Failure" and discard the packet. 1893 Note that one possible authentication failure is the lack of an 1894 Authentication Extension; the presence or absence of the 1895 Authentication Extension is a local matter. 1897 0 1 2 3 1898 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 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | Authentication Type | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | | 1903 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1904 | | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 The Authentication Type field identifies the authentication method in 1908 use. Currently assigned values are: 1910 1 - Cleartext Password 1911 2 - Keyed MD5 1913 All other values are reserved. 1915 The Authentication Data field contains the type-specific 1916 authentication information. 1918 In the case of Cleartext Password Authentication, the Authentication 1919 Data consists of a variable length password. 1921 In the case of Keyed MD5 Authentication, the Authentication Data 1922 contains the 16 byte MD5 digest of the entire NHRP packet, including 1923 the encapsulated protocol's header, with the authentication key 1924 appended to the end of the packet. The authentication key is not 1925 transmitted with the packet. The MD5 digest covers only the 1926 following fields of the NHRP packet: fixed part (with hop count, 1927 packet size and checksum being set to zero), mandatory part, 1928 Responder Address extension, and authentication extension. Note that 1929 when MD5 is used, there is an explicit ordering of the extensions 1930 such that: if the Responder Address extension exists then it MUST be 1931 the first extension in the packet and the Authentication Extension 1932 MUST be the second extension otherwise the Authentication Extension 1933 MUST be the first extension in the packet. 1935 Distribution of authentication keys is outside the scope of this 1936 document. 1938 5.3.5 NHRP Vendor-Private Extension 1940 Compulsory = 0 1941 Type = 8 1942 Length = variable 1944 The NHRP Vendor-Private Extension is carried in NHRP packets to 1945 convey vendor-private information or NHRP extensions between NHRP 1946 speakers. 1948 0 1 2 3 1949 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 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 | Vendor ID | Data.... | 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 Vendor ID 1955 802 Vendor ID as assigned by the IEEE [6] 1957 Data 1958 The remaining octets after the Vendor ID in the payload are 1959 vendor-dependent data. 1961 This extension may be added to any "request" or "reply" packet and it 1962 is the only extension that may be included multiple times. If the 1963 receiver does not handle this extension, or does not match the Vendor 1964 ID in the extension then the extension may be completely ignored by 1965 the receiver. If a Vendor Private Extension is included in a 1966 "request" then is must be copied in the corresponding "reply". 1968 6. Protocol Operation 1970 In this section, we discuss certain operational considerations of 1971 NHRP. 1973 6.1 Router-to-Router Operation 1975 In practice, the initiating and responding stations may be either 1976 hosts or routers. However, there is a possibility under certain 1977 conditions that a stable routing loop may occur if NHRP is used 1978 between two routers. In particular, attempting to establish an NHRP 1979 path across a boundary where information used in route selection is 1980 lost may result in a routing loop. Such situations include the loss 1981 of BGP path vector information, the interworking of multiple routing 1982 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 1983 circumstances, NHRP should not be used. This situation can be 1984 avoided if there are no "back door" paths between the entry and 1985 egress router outside of the NBMA subnetwork. Protocol mechanisms to 1986 relax these restrictions are under investigation. 1988 In general it is preferable to use mechanisms, if they exist, in 1989 routing protocols to resolve the egress point when the destination 1990 lies outside of the NBMA subnetwork, since such mechanisms will be 1991 more tightly coupled to the state of the routing system and will 1992 probably be less likely to create loops. 1994 6.2 Cache Management Issues 1996 The management of NHRP caches in the source station, the NHS serving 1997 the destination, and any intermediate NHSs is dependent on a number 1998 of factors. 2000 6.2.1 Caching Requirements 2002 Source Stations 2004 Source stations MUST cache all received NHRP Resolution Replies 2005 that they are actively using. They also must cache "incomplete" 2006 entries, i.e., those for which a NHRP Resolution Request has been 2007 sent but those for which an NHRP Resolution Reply has not been 2008 received. This is necessary in order to preserve the Request ID 2009 for retries, and provides the state necessary to avoid triggering 2010 NHRP Resolution Requests for every data packet sent to the 2011 destination. 2013 Source stations MUST purge expired information from their caches. 2014 Source stations MUST purge the appropriate cached information upon 2015 receipt of an NHRP Purge Request packet. 2017 When a station has a co-resident NHC and NHS, the co-resident NHS 2018 may reply to NHRP Resolution Requests from the co-resident NHC with 2019 information which the station cached as a result of the co-resident 2020 NHC making its own NHRP Resolution Requests as long as the co- 2021 resident NHS follows the rules for Transit NHSs as seen below. 2023 Serving NHSs 2025 The NHS serving the destination (the one which responds 2026 authoritatively to NHRP Resolution Requests) SHOULD cache protocol 2027 address information from all NHRP Resolution Requests to which it 2028 has responded if the information in the NHRP Resolution Reply has 2029 the possibility of changing during its lifetime (so that an NHRP 2030 Purge Request packet can be issued). The internetworking to NBMA 2031 binding information provided by the source station in the NHRP 2032 Resolution Request may also be cached if and only if the "S" bit is 2033 set, the NHRP Resolution Request has included a CIE with the 2034 Holding Time field set greater than zero (this is the valid Holding 2035 Time for the source binding), and only for non-authoritative use 2036 for a period not to exceed the Holding Time. 2038 Transit NHSs 2040 A Transit NHS (lying along the NHRP path between the source station 2041 and the responding NHS) may cache source binding information 2042 contained in NHRP Resolution Request packets that it forwards if 2043 and only if the "S" bit is set, the NHRP Resolution Request has 2044 included a CIE with the Holding Time field set greater than zero 2045 (this is the valid Holding Time for the source binding), and only 2046 for non-authoritative use for a period not to exceed the Holding 2047 Time. 2049 A Transit NHS may cache destination information contained in NHRP 2050 Resolution Reply CIE if only if the D bit is set and then only for 2051 non-authoritative use for a period not to exceed the Holding Time 2052 value contained in the CIE. A Transit NHS MUST NOT cache source 2053 binding information contained in an NHRP Resolution Reply. 2055 Further, a transit NHS MUST discard any cached information when the 2056 prescribed time has expired. It may return cached information in 2057 response to non-authoritative NHRP Resolution Requests only. 2059 6.2.2 Dynamics of Cached Information 2061 NBMA-Connected Destinations 2063 NHRP's most basic function is that of simple NBMA address 2064 resolution of stations directly attached to the NBMA subnetwork. 2065 These mappings are typically very static, and appropriately chosen 2066 holding times will minimize problems in the event that the NBMA 2067 address of a station must be changed. Stale information will cause 2068 a loss of connectivity, which may be used to trigger an 2069 authoritative NHRP Resolution Request and bypass the old data. In 2070 the worst case, connectivity will fail until the cache entry times 2071 out. 2073 This applies equally to information marked in NHRP Resolution 2074 Replies as being "stable" (via the "D" bit). 2076 Destinations Off of the NBMA Subnetwork 2078 If the source of an NHRP Resolution Request is a host and the 2079 destination is not directly attached to the NBMA subnetwork, and 2080 the route to that destination is not considered to be "stable," the 2081 destination mapping may be very dynamic (except in the case of a 2082 subnetwork where each destination is only singly homed to the NBMA 2083 subnetwork). As such the cached information may very likely become 2084 stale. The consequence of stale information in this case will be a 2085 suboptimal path (unless the internetwork has partitioned or some 2086 other routing failure has occurred). 2088 6.3 Use of the Prefix Length field of a CIE 2090 A certain amount of care needs to be taken when using the Prefix 2091 Length field of a CIE, in particular with regard to the prefix length 2092 advertised (and thus the size of the equivalence class specified by 2093 it). Assuming that the routers on the NBMA subnetwork are exchanging 2094 routing information, it should not be possible for an NHS to create a 2095 black hole by advertising too large of a set of destinations, but 2096 suboptimal routing (e.g., extra internetwork layer hops through the 2097 NBMA) can result. To avoid this situation an NHS that wants to send 2098 the Prefix Length MUST obey the following rule: 2100 The NHS examines the Network Layer Reachability Information (NLRI) 2101 associated with the route that the NHS would use to forward towards 2102 the destination (as specified by the Destination internetwork layer 2103 address in the NHRP Resolution Request), and extracts from this 2104 NLRI the shortest address prefix such that: (a) the Destination 2105 internetwork layer address (from the NHRP Resolution Request) is 2106 covered by the prefix, (b) the NHS does not have any routes with 2107 NLRI which form a subset of what is covered by the prefix. The 2108 prefix may then be used in the CIE. 2110 The Prefix Length field of the CIE should be used with restraint, in 2111 order to avoid NHRP stations choosing suboptimal transit paths when 2112 overlapping prefixes are available. This document specifies the use 2113 of the prefix length only when all the destinations covered by the 2114 prefix are "stable". That is, either: 2116 (a) All destinations covered by the prefix are on the NBMA network, or 2118 (b) All destinations covered by the prefix are directly attached to 2119 the NHRP responding station. 2121 Use of the Prefix Length field of the CIE in other circumstances is 2122 outside the scope of this document. 2124 6.4 Domino Effect 2126 One could easily imagine a situation where a router, acting as an 2127 ingress station to the NBMA subnetwork, receives a data packet, such 2128 that this packet triggers an NHRP Resolution Request. If the router 2129 forwards this data packet without waiting for an NHRP transit path to 2130 be established, then when the next router along the path receives the 2131 packet, the next router may do exactly the same - originate its own 2132 NHRP Resolution Request (as well as forward the packet). In fact 2133 such a data packet may trigger NHRP Resolution Request generation at 2134 every router along the path through an NBMA subnetwork. We refer to 2135 this phenomena as the NHRP "domino" effect. 2137 The NHRP domino effect is clearly undesirable. At best it may result 2138 in excessive NHRP traffic. At worst it may result in an excessive 2139 number of virtual circuits being established unnecessarily. 2140 Therefore, it is important to take certain measures to avoid or 2141 suppress this behavior. NHRP implementations for NHSs MUST provide a 2142 mechanism to address this problem. One possible strategy to address 2143 this problem would be to configure a router in such a way that NHRP 2144 Resolution Request generation by the router would be driven only by 2145 the traffic the router receives over its non-NBMA interfaces 2146 (interfaces that are not attached to an NBMA subnetwork). Traffic 2147 received by the router over its NBMA-attached interfaces would not 2148 trigger NHRP Resolution Requests. Such a router avoids the NHRP 2149 domino effect through administrative means. 2151 7. NHRP over Legacy BMA Networks 2153 There would appear to be no significant impediment to running NHRP 2154 over legacy broadcast subnetworks. There may be issues around 2155 running NHRP across multiple subnetworks. Running NHRP on broadcast 2156 media has some interesting possibilities; especially when setting up 2157 a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both 2158 end stations are legacy attached. This use for NHRP requires further 2159 research. 2161 8. Security Considerations 2163 As in any resolution protocol, there are a number of potential 2164 security attacks possible. Plausible examples include denial-of- 2165 service attacks, and masquerade attacks using register and purge 2166 packets. The use of authentication on all packets is recommended to 2167 avoid such attacks. 2169 The authentication schemes described in this document are intended to 2170 allow the receiver of a packet to validate the identity of the 2171 sender; they do not provide privacy or protection against replay 2172 attacks. 2174 Detailed security analysis of this protocol is for further study. 2176 9. Discussion 2178 The result of an NHRP Resolution Request depends on how routing is 2179 configured among the NHSs of an NBMA subnetwork. If the destination 2180 station is directly connected to the NBMA subnetwork and the the 2181 routed path to it lies entirely within the NBMA subnetwork, the NHRP 2182 Resolution Replies always return the NBMA address of the destination 2183 station itself rather than the NBMA address of some egress router. 2184 On the other hand, if the routed path exits the NBMA subnetwork, NHRP 2185 will be unable to resolve the NBMA address of the destination, but 2186 rather will return the address of the egress router. For 2187 destinations outside the NBMA subnetwork, egress routers and routers 2188 in the other subnetworks should exchange routing information so that 2189 the optimal egress router may be found. 2191 In addition to NHSs, an NBMA station could also be associated with 2192 one or more regular routers that could act as "connectionless 2193 servers" for the station. The station could then choose to resolve 2194 the NBMA next hop or just send the packets to one of its 2195 connectionless servers. The latter option may be desirable if 2196 communication with the destination is short-lived and/or doesn't 2197 require much network resources. The connectionless servers could, of 2198 course, be physically integrated in the NHSs by augmenting them with 2199 internetwork layer switching functionality. 2201 References 2203 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 2204 Govindan, RFC1735. 2206 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 2208 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 2210 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 2211 and D. Piscitello, RFC 1209. 2213 [5] Protocol Identification in the Network Layer, ISO/IEC TR 2214 9577:1990. 2216 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 2218 [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, 2219 RFC1483. 2221 [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, 2222 A. Malis, D. Robinson, and R. Ullmann, RFC1356. 2224 [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and 2225 A. Malis, RFC1490. 2227 [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, 2228 Yakov Rekhter, Dilip Kandlur, RFC1937. 2230 [11] Support for Multicast over UNI 3.0/3.1 based ATM Networks, 2231 G. Armitage, Work In Progress. 2233 [12] Server Cache Synchronization Protocol (SCSP) - NBMA, 2234 J. Luciani, G. Armitage, J. Halpern, Work In Progress. 2236 [13] NHRP for Destinations off the NBMA Subnetwork, 2237 Y. Rekhter, Work In Progress. 2239 [14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress. 2241 Acknowledgments 2243 We would like to thank (in no particular order) Juha Heinenan of 2244 Telecom Finland and Ramesh Govidan of ISI for their work on NBMA ARP 2245 and the original NHRP draft, which served as the basis for this work. 2246 Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of 2247 ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul 2248 Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco, 2249 and Grenville Armitage of Bellcore should also be acknowledged for 2250 comments and suggestions that improved this work substantially. We 2251 would also like to thank the members of the ION working group of the 2252 IETF, whose review and discussion of this document have been 2253 invaluable. 2255 Authors' Addresses 2257 James V. Luciani Dave Katz 2258 Bay Networks cisco Systems 2259 3 Federal Street 170 W. Tasman Dr. 2260 Mail Stop: BL3-04 San Jose, CA 95134 USA 2261 Billerica, MA 01821 Phone: +1 408 526 8284 2262 Phone: +1 508 916 4734 Email: dkatz@cisco.com 2263 Email: luciani@baynetworks.com 2265 David Piscitello Bruce Cole 2266 Core Competence Juniper Networks 2267 1620 Tuckerstown Road 3260 Jay St. 2268 Dresher, PA 19025 USA Santa Clara, CA 95054 2269 Phone: +1 215 830 0692 Phone: +1 408 327 1900 2270 Email: dave@corecom.com Email: bcole@jnx.com