idnits 2.17.1 draft-ietf-rolc-nhrp-10.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-26) 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 338: '...s not exists then one MUST be created....' RFC 2119 keyword, line 428: '... Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used...' RFC 2119 keyword, line 449: '... an NHC, the NHS MUST send NHRP messag...' (105 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 958 has weird spacing: '... wishes to r...' == Line 1894 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 (March 1997) is 9904 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 547 -- Looks like a reference, but probably isn't: '0x00-00-5E' on line 547 -- Looks like a reference, but probably isn't: '0x00-03' on line 547 == Unused Reference: '2' is defined on line 2170, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2177, 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 (cisco Systems) 9 Expires March 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 An NHRP Resolution Reply may be returned directly to the NHRP 297 Resolution Request initiator, without traversing the NHSs which 298 forwarded the NHRP Resolution Request, if each of the following 299 criteria are satisfied: 301 (a) Direct communication is available via datagram transfer 302 (e.g., SMDS) or the NHS has an existing virtual circuit 303 connection to the NHC which sent the NHRP Resolution Request 304 or NHS is permitted to open a connection the NHC. 305 (b) The NHRP Resolution Request initiator has not included the 306 NHRP Reverse NHS record Extension (see Section 5.3.3). 307 (c) The authentication policy in force permits direct 308 communication between the NHS and the NHRP Resolution 309 Request initiator. 311 The purpose of allowing an NHS to send a NHRP Resolution Reply 312 directly is to reduce response time. A consequence of allowing a 313 direct NHRP Resolution Reply is that NHSs that would under normal 314 circumstances be traversed by the NHRP Resolution Reply would not 315 cache next hop information contained therein. This feature may have 316 value when the serving NHS is an egress router for the destination 317 address which is off the NBMA cloud (this implies that NHC 318 functionality is coresident with the NHS). 320 If the determination is made that no NHS in the NBMA subnetwork can 321 reply to the NHRP Resolution Request for D then a negative NHRP 322 Resolution Reply (NAK) is returned. This occurs when (a) no next-hop 323 resolution information is available for station D from any NHS, or 324 (b) an NHS is unable to forward the NHRP Resolution Request (e.g., 325 connectivity is lost). 327 NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, 328 and NHRP Error Indications follow a routed path in the same fashion 329 that NHRP Resolution Requests and NHRP Resolution Replies do. 330 Specifically, "requests" and "indications" follow the routed path 331 from Source Protocol Address (which is the address of the station 332 initiating the communication) to the Destination Protocol Address. 333 "Replies", on the other hand, follow the routed path from the 334 Destination Protocol Address back to the Source Protocol Address with 335 the following exceptions: in the case of a NHRP Registration Reply 336 and in the case of an NHC initiated NHRP Purge Request, the packet is 337 always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if 338 one does not exists then one MUST be created. 340 NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA 341 subnetwork however further study is being done in this area (see 342 Section 7). Thus, the internetwork layer traffic out of and into an 343 NBMA subnetwork always traverses an internetwork layer router at its 344 border. Internetwork layer filtering can then be implemented at 345 these border routers. 347 NHRP optionally provides a mechanism to send a NHRP Resolution Reply 348 which contains aggregated address resolution information. For 349 example, suppose that router X is the next hop from station S to 350 station D and that X is an egress router for all stations sharing an 351 internetwork layer address prefix with station D. When an NHRP 352 Resolution Reply is generated in response to a NHRP Resolution 353 Request, the responder may augment the internetwork layer address of 354 station D with a prefix length (see Section 5.2.0.1). A subsequent 355 (non-authoritative) NHRP Resolution Request for some destination that 356 shares an internetwork layer address prefix (for the number of bits 357 specified in the prefix length) with D may be satisfied with this 358 cached information. See section 6.2 regarding caching issues. 360 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 361 (e.g., X.25 closed user group facility, or SMDS address screens), to 362 trace the routed path that an NHRP packet takes, or to provide loop 363 detection and diagnostic capabilities, a "Route Record" may be 364 included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route 365 Record extensions are the NHRP Forward Transit NHS Record Extension 366 and the NHRP Reverse Transit NHS Record Extension. They contain the 367 internetwork (and subnetwork layer) addresses of all intermediate 368 NHSs between source and destination and between destination and 369 source respectively. When a source station is unable to communicate 370 with the responder (e.g., an attempt to open an SVC fails), it may 371 attempt to do so successively with other subnetwork layer addresses 372 in the NHRP Forward Transit NHS Record Extension until it succeeds 373 (if authentication policy permits such action). This approach can 374 find a suitable egress point in the presence of subnetwork-layer 375 filtering (which may be source/destination sensitive, for instance, 376 without necessarily creating separate logical NBMA subnetworks) or 377 subnetwork-layer congestion (especially in connection-oriented 378 media). 380 3. Deployment 382 NHRP Resolution Requests traverse one or more hops within an NBMA 383 subnetwork before reaching the station that is expected to generate a 384 response. Each station, including the source station, chooses a 385 neighboring NHS to which it will forward the NHRP Resolution Request. 386 The NHS selection procedure typically involves applying a destination 387 protocol layer address to the protocol layer routing table which 388 causes a routing decision to be returned. This routing decision is 389 then used to forward the NHRP Resolution Request to the downstream 390 NHS. The destination protocol layer address previously mentioned is 391 carried within the NHRP Resolution Request packet. Note that even 392 though a protocol layer address was used to acquire a routing 393 decision, NHRP packets are not encapsulated within a protocol layer 394 header but rather are carried at the NBMA layer using the 395 encapsulation described in Section 5. 397 Each NHS/router examines the NHRP Resolution Request packet on its 398 way toward the destination. Each NHS which the NHRP packet traverses 399 on the way to the packet's destination might modify the packet (e.g., 400 updating the Forward Record extension). Ignoring error situations, 401 the NHRP Resolution Request eventually arrives at a station that is 402 to generate an NHRP Resolution Reply. This responding station 403 "serves" the destination. The responding station generates a NHRP 404 Resolution Reply using the source protocol address from within the 405 NHRP packet to determine where the NHRP Resolution Reply should be 406 sent. 408 Rather than use routing to determine the next hop for an NHRP packet, 409 an NHS may use other applicable means (such as static configuration 410 information ) in order to determine to which neighboring NHSs to 411 forward the NHRP Resolution Request packet as long as such other 412 means would not cause the NHRP packet to arrive at an NHS which is 413 not along the routed path. The use of static configuration 414 information for this purpose is beyond the scope of this document. 416 The NHS serving a particular destination must lie along the routed 417 path to that destination. In practice, this means that all egress 418 routers must double as NHSs serving the destinations beyond them, and 419 that hosts on the NBMA subnetwork are served by routers that double 420 as NHSs. Also, this implies that forwarding of NHRP packets within 421 an NBMA subnetwork requires a contiguous deployment of NHRP capable 422 routers. It is important that, in a given LIS/LAG which is using 423 NHRP, all NHSs within the LIS/LAG have at least some portion of their 424 resolution databases synchronized so that a packet arriving at one 425 router/NHS in a given LIS/LAG will be forwarded in the same fashion 426 as packet arriving at a different router/NHS for the given LIS/LAG. 427 One method, among others, is to use the Server Cache Synchronization 428 Protocol (SCSP) [12]. It is RECOMMENDED that SCSP be the method used 429 when a LIS/LAG contains two or more router/NHSs. 431 During migration to NHRP, it cannot be expected that all routers 432 within the NBMA subnetwork are NHRP capable. Thus, NHRP traffic 433 which would otherwise need to be forwarded through such routers can 434 be expected to be dropped due to the NHRP packet not being 435 recognized. In this case, NHRP will be unable to establish any 436 transit paths whose discovery requires the traversal of the non-NHRP 437 speaking routers. If the client has tried and failed to acquire a 438 cut through path then the client should use the network layer routed 439 path as a default. 441 If an NBMA technology offers a group, an anycast, or a multicast 442 addressing feature then the NHC may be configured with such an 443 address which would be assigned to the appropriate NHSs. The NHC 444 might then submit NHRP Resolution Requests to such an address, 445 eliciting a response from one or more NHSs, depending on the response 446 strategy selected. Note that the constraints described in Section 2 447 regarding directly sending NHRP Resolution Reply may apply. 449 When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined 450 for the NHC directly to the NHC. That is, the NHRP message MUST NOT 451 transit through any NHS which is not serving the NHC when the NHRP 452 message is currently at an NHS which does serve the NHC (this, of 453 course, assumes the NHRP message is destined for the NHC). Further, 454 an NHS which serves an NHC SHOULD have a direct NBMA level connection 455 to that NHC (see Section 5.2.3 and 5.2.4 for examples). 457 With the exception of NHRP Registration Requests (see Section 5.2.3 458 and 5.2.4 for details of the NHRP Registration Request case), an NHC 459 MUST send NHRP messages over a direct NBMA level connection between 460 the serving NHS and the served NHC. 462 It may not be desirable to maintain semi-permanent NBMA level 463 connectivity between the NHC and the NHS. In this case, when NBMA 464 level connectivity is initially setup between the NHS and the NHC (as 465 described in Section 5.2.4), the NBMA address of the NHS should be 466 obtained through the NBMA level signaling technology. This address 467 should be stored for future use in setting up subsequent NBMA level 468 connections. A somewhat more information rich technique to obtain 469 the address information (and more) of the serving NHS would be for 470 the NHC to include the Responder Address extension (see Section 471 5.3.1) in the NHRP Registration Request and to store the information 472 returned to the NHC in the Responder Address extension which is 473 subsequently included in the NHRP Registration Reply. Note also 474 that, in practice, a client's default router should also be its NHS; 475 thus a client may be able to know the NBMA address of its NHS from 476 the configuration which was already required for the client to be 477 able to communicate. Further, as mentioned in Section 4, NHCs may be 478 configured with the addressing information of one or more NHSs. 480 4. Configuration 482 Next Hop Clients 484 An NHC connected to an NBMA subnetwork MAY be configured with the 485 Protocol address(es) and NBMA address(es) of its NHS(s). The 486 NHS(s) will likely also represent the NHC's default or peer 487 routers, so their NBMA addresses may be obtained from the NHC's 488 existing configuration. If the NHC is attached to several 489 subnetworks (including logical NBMA subnetworks), the NHC should 490 also be configured to receive routing information from its NHS(s) 491 and peer routers so that it can determine which internetwork layer 492 networks are reachable through which subnetworks. 494 Next Hop Servers 496 An NHS is configured with knowledge of its own internetwork layer 497 and NBMA addresses. An NHS MAY also be configured with a set of 498 internetwork layer address prefixes that correspond to the 499 internetwork layer addresses of the stations it serves. The NBMA 500 addresses of the stations served by the NHS may be learned via NHRP 501 Registration packets. 503 If a served NHC is attached to several subnetworks, the 504 router/route-server coresident with the serving NHS may also need 505 to be configured to advertise routing information to such NHCs. 507 If an NHS acts as an egress router for stations connected to other 508 subnetworks than the NBMA subnetwork, the NHS must, in addition to 509 the above, be configured to exchange routing information between 510 the NBMA subnetwork and these other subnetworks. 512 In all cases, routing information is exchanged using conventional 513 intra-domain and/or inter-domain routing protocols. 515 5. NHRP Packet Formats 516 This section describes the format of NHRP packets. In the following, 517 unless otherwise stated explicitly, the unqualified term "request" 518 refers generically to any of the NHRP packet types which are 519 "requests". Further, unless otherwise stated explicitly, the 520 unqualified term "reply" refers generically to any of the NHRP packet 521 types which are "replies". 523 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 524 Extensions Part. The Fixed Part is common to all NHRP packet types. 525 The Mandatory Part MUST be present, but varies depending on packet 526 type. The Extensions Part also varies depending on packet type, and 527 need not be present. 529 The length of the Fixed Part is fixed at 20 octets. The length of 530 the Mandatory Part is determined by the contents of the extensions 531 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 532 length is equal to total packet length (ar$pktsz) minus 20 otherwise 533 the mandatory part length is equal to ar$extoff minus 20. The length 534 of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs 535 may increase the size of an NHRP packet as a result of extension 536 processing, but not beyond the offered maximum SDU size of the NBMA 537 network. 539 NHRP packets are actually members of a wider class of address mapping 540 and management protocols being developed by the IETF. A specific 541 encapsulation, based on the native formats used on the particular 542 NBMA network over which NHRP is carried, indicates the generic IETF 543 mapping and management protocol. For example, SMDS networks always 544 use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet 545 is preceded by the following LLC/SNAP encapsulation: 547 [0xAA-AA-03] [0x00-00-5E] [0x00-03] 549 The first three octets are LLC, indicating that SNAP follows. The 550 SNAP OUI portion is the IANA's OUI, and the SNAP PID portion 551 identifies the mapping and management protocol. A field in the Fixed 552 Header following the encapsulation indicates that it is NHRP. 554 ATM uses either LLC/SNAP encapsulation of each packet (including 555 NHRP), or uses no encapsulation on VCs dedicated to a single protocol 556 (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or 557 identification of NHRP, using a NLPID of 0x0080 and the same SNAP 558 contents as above (see [8], [9]). 560 Fields marked "unused" MUST be set to zero on transmission, and 561 ignored on receipt. 563 Most packet types (ar$op.type) have both internetwork layer 564 protocol-independent fields and protocol-specific fields. The 565 protocol type/snap fields (ar$pro.type/snap) qualify the format of 566 the protocol-specific fields. 568 5.1 NHRP Fixed Header 570 The Fixed Part of the NHRP packet contains those elements of the NHRP 571 packet which are always present and do not vary in size with the type 572 of packet. 574 0 1 2 3 575 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | ar$afn | ar$pro.type | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | ar$pro.snap | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | ar$pro.snap | ar$hopcnt | ar$pktsz | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | ar$chksum | ar$extoff | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | ar$op.version | ar$op.type | ar$shtl | ar$sstl | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ar$afn 589 Defines the type of "link layer" addresses being carried. This 590 number is taken from the 'address family number' list specified in 591 [6]. This field has implications to the coding of ar$shtl and 592 ar$sstl as described below. 594 ar$pro.type 595 field is a 16 bit unsigned integer representing the following 596 number space: 598 0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 599 0x0100 to 0x03FF Reserved for future use by the IETF. 600 0x0400 to 0x04FF Allocated for use by the ATM Forum. 601 0x0500 to 0x05FF Experimental/Local use. 602 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 604 (based on the observations that valid Ethertypes are never smaller 605 than 0x600, and NLPIDs never larger than 0xFF.) 607 ar$pro.snap 608 When ar$pro.type has a value of 0x0080, a SNAP encoded extension is 609 being used to encode the protocol type. This snap extension is 610 placed in the ar$pro.snap field. This is termed the 'long form' 611 protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be 612 zero on transmit and ignored on receive. The ar$pro.type field 613 itself identifies the protocol being referred to. This is termed 614 the 'short form' protocol ID. 616 In all cases, where a protocol has an assigned number in the 617 ar$pro.type space (excluding 0x0080) the short form MUST be used 618 when transmitting NHRP messages; i.e., if Ethertype or NLPID 619 codings exist then they are used on transmit rather than the 620 ethertype. If both Ethertype and NLPID codings exist then when 621 transmitting NHRP messages, the Ethertype coding MUST be used (this 622 is consistent with RFC 1483 coding). So, for example, the 623 following codings exist for IP: 625 SNAP: ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00 626 NLPID: ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00 627 Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00 629 and thus, since the Ethertype coding exists, it is used in 630 preference. 632 ar$hopcnt 633 The Hop count indicates the maximum number of NHSs that an NHRP 634 packet is allowed to traverse before being discarded. 636 ar$pktsz 637 The total length of the NHRP packet, in octets (excluding link 638 layer encapsulation). 640 ar$chksum 641 The standard IP checksum over the entire NHRP packet (starting with 642 the fixed header). If only the hop count field is changed, the 643 checksum is adjusted without full recomputation. The checksum is 644 completely recomputed when other header fields are changed. 646 ar$extoff 647 This field identifies the existence and location of NHRP 648 extensions. If this field is 0 then no extensions exist otherwise 649 this field represents the offset from the beginning of the NHRP 650 packet (i.e., starting from the ar$afn field) of the first 651 extension. 653 ar$op.version 654 This field indicates what version of generic address mapping and 655 management protocol is represented by this message. 657 0 MARS protocol [11]. 658 1 NHRP as defined in this document. 659 0x02 - 0xEF Reserved for future use by the IETF. 660 0xF0 - 0xFE Allocated for use by the ATM Forum. 661 0xFF Experimental/Local use. 663 ar$op.type 664 When ar$op.version == 1, this is the NHRP packet type: NHRP 665 Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration 666 Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP 667 Purge Reply(6), or NHRP Error Indication(7). Use of NHRP packet 668 Types in the range 128 to 255 are reserved for research or use in 669 other protocol development and will be administered by IANA. 671 ar$shtl 672 Type & length of source NBMA address interpreted in the context of 673 the 'address family number'[6] indicated by ar$afn. See below for 674 more details. 676 ar$sstl 677 Type & length of source NBMA subaddress interpreted in the context 678 of the 'address family number'[6] indicated by ar$afn. When an 679 NBMA technology has no concept of a subaddress, the subaddress 680 length is always coded ar$sstl = 0 and no storage is allocated for 681 the subaddress in the appropriate mandatory part. See below for 682 more details. 684 Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr 685 T/L) and subnetwork layer subaddresses type/length fields (e.g., 686 ar$sstl, Cli SAddr T/L) are coded as follows: 688 7 6 5 4 3 2 1 0 689 +-+-+-+-+-+-+-+-+ 690 |0|x| length | 691 +-+-+-+-+-+-+-+-+ 693 The most significant bit is reserved and MUST be set to zero. The 694 second most significant bit (x) is a flag indicating whether the 695 address being referred to is in: 697 - NSAP format (x = 0). 698 - Native E.164 format (x = 1). 700 For NBMA technologies that use neither NSAP nor E.164 format 701 addresses, x = 0 SHALL be used to indicate the native form for the 702 particular NBMA technology. 704 If the NBMA network is ATM and a subaddress (e.g., Source NBMA 705 SubAddress, Client NBMA SubAddress) is to be included in any part of 706 the NHRP packet then ar$afn MUST be set to 0x000F; further, the 707 subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr 708 T/L) and subnetwork layer subaddress type/length fields (e.g., 709 ar$sstl, Cli SAddr T/L) MUST be coded as in [11]. If the NBMA 710 network is ATM and no subaddress field is to be included in any part 711 of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008 712 (E.164) accordingly. 714 The bottom 6 bits is an unsigned integer value indicating the length 715 of the associated NBMA address in octets. If this value is zero the 716 flag x is ignored. 718 5.2.0 Mandatory Part 720 The Mandatory Part of the NHRP packet contains the operation specific 721 information (e.g., NHRP Resolution Request/Reply, etc.) and variable 722 length data which is pertinent to the packet type. 724 5.2.0.1 Mandatory Part Format 726 Sections 5.2.1 through 5.2.6 have a very similar mandatory part. 727 This mandatory part includes a common header and zero or more Client 728 Information Entries (CIEs). Section 5.2.7 has a different format 729 which is specified in that section. 731 The common header looks like the following: 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Src Proto Len | Dst Proto Len | Flags | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Request ID | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Source NBMA Address (variable length) | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Source NBMA Subaddress (variable length) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Source Protocol Address (variable length) | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Destination Protocol Address (variable length) | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 And the CIEs have the following format: 751 0 1 2 3 752 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Code | Prefix Length | unused | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Maximum Transmission Unit | Holding Time | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Client NBMA Address (variable length) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Client NBMA Subaddress (variable length) | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Client Protocol Address (variable length) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 ..................... 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Code | Prefix Length | unused | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Maximum Transmission Unit | Holding Time | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Client NBMA Address (variable length) | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Client NBMA Subaddress (variable length) | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Client Protocol Address (variable length) | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 The meanings of the fields are as follows: 783 Src Proto Len 784 This field holds the length in octets of the Source Protocol 785 Address. 787 Dst Proto Len 788 This field holds the length in octets of the Destination Protocol 789 Address. 791 Flags 792 These flags are specific to the given message type and they are 793 explained in each section. 795 Request ID 796 A value which, when coupled with the address of the source, 797 provides a unique identifier for the information contained in a 798 "request" packet. This value is copied directly from an "request" 799 packet into the associated "reply". When a sender of a "request" 800 receives "reply", it will compare the Request ID and source address 801 information in the received "reply" against that found in its 802 outstanding "request" list. When a match is found then the 803 "request" is considered to be acknowledged. 805 The value is taken from a 32 bit counter that is incremented each 806 time a new "request" is transmitted. The same value MUST be used 807 when resending a "request", i.e., when a "reply" has not been 808 received for a "request" and a retry is sent after an appropriate 809 interval. 811 The NBMA address/subaddress form specified below allows combined 812 E.164/NSAPA form of NBMA addressing. For NBMA technologies without a 813 subaddress concept, the subaddress field is always ZERO length and 814 ar$sstl = 0. 816 Source NBMA Address 817 The Source NBMA address field is the address of the source station 818 which is sending the "request". If the field's length as specified 819 in ar$shtl is 0 then no storage is allocated for this address at 820 all. 822 Source NBMA SubAddress 823 The Source NBMA subaddress field is the address of the source 824 station which is sending the "request". If the field's length as 825 specified in ar$sstl is 0 then no storage is allocated for this 826 address at all. 828 "Requests" and "indications" follow the routed path from Source 829 Protocol Address to the Destination Protocol Address. "Replies", on 830 the other hand, follow the routed path from the Destination Protocol 831 Address back to the Source Protocol Address with the following 832 exceptions: in the case of a NHRP Registration Reply and in the case 833 of an NHC initiated NHRP Purge Request, the packet is always returned 834 via a direct VC (see Sections 5.2.4 and 5.2.5). 836 Source Protocol Address 837 This is the protocol address of the station which is sending the 838 "request". This is also the protocol address of the station toward 839 which a "reply" packet is sent. 841 Destination Protocol Address 842 This is the protocol address of the station toward which a 843 "request" packet is sent. 845 Code 846 This field is message specific. See the relevant message sections 847 below. In general, this field is a NAK code; i.e., when the field 848 is 0 in a reply then the packet is acknowledging a request and if 849 it contains any other value the packet contains a negative 850 acknowledgment. 852 Prefix Length 853 This field is message specific. See the relevant message sections 854 below. In general, however, this fields is used to indicate that 855 the information carried in an NHRP message pertains to an 856 equivalence class of internetwork layer addresses rather than just 857 a single internetwork layer address specified. All internetwork 858 layer addresses that match the first "Prefix Length" bit positions 859 for the specific internetwork layer address are included in the 860 equivalence class. If this field is set to 0x00 then this field 861 MUST be ignored and no equivalence information is assumed (note 862 that 0x00 is thus equivalent to 0xFF). 864 Maximum Transmission Unit 865 This field gives the maximum transmission unit for the relevant 866 client station. If this value is 0 then either the default MTU is 867 used or the MTU negotiated via signaling is used if such 868 negotiation is possible for the given NBMA. 870 Holding Time 871 The Holding Time field specifies the number of seconds for which 872 the Next Hop NBMA information specified in the CIE is considered to 873 be valid. Cached information SHALL be discarded when the holding 874 time expires. This field must be set to 0 on a NAK. 876 Cli Addr T/L 877 Type & length of next hop NBMA address specified in the CIE. This 878 field is interpreted in the context of the 'address family 879 number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM). 881 Cli SAddr T/L 882 Type & length of next hop NBMA subaddress specified in the CIE. 883 This field is interpreted in the context of the 'address family 884 number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes 885 the address an E.164 and the subaddress an ATM Forum NSAP address). 886 When an NBMA technology has no concept of a subaddress, the 887 subaddress is always null with a length of 0. When the address 888 length is specified as 0 no storage is allocated for the address. 890 Cli Proto Len 891 This field holds the length in octets of the Client Protocol 892 Address specified in the CIE. 894 Preference 895 This field specifies the preference for use of the specific CIE 896 relative to other CIEs. Higher values indicate higher preference. 897 Action taken when multiple CIEs have equal or highest preference 898 value is a local matter. 900 Client NBMA Address 901 This is the client's NBMA address. 903 Client NBMA SubAddress 904 This is the client's NBMA subaddress. 906 Client Protocol Address 907 This is the client's internetworking layer address specified. 909 Note that an NHS SHOULD NOT cache source information which is in an 910 NHRP message because this information could be inappropriately used 911 to set up a cut-through without doing proper filtering along a routed 912 path. Further, in the case where a distributed router exists in the 913 network, incorrect or incomplete information may be included in the 914 source information. 916 5.2.1 NHRP Resolution Request 918 The NHRP Resolution Request packet has a Type code of 1. Its 919 mandatory part is coded as described in Section 5.2.0.1 and the 920 message specific meanings of the fields are as follows: 922 Flags - The flags field is coded as follows: 924 0 1 925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 |Q|A|B|U| unused | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Q 931 Set if the station sending the NHRP Resolution Request is a 932 router; clear if the it is a host. 934 A 935 This bit is set in a NHRP Resolution Request if only 936 authoritative next hop information is desired and is clear 937 otherwise. See the NHRP Resolution Reply section below for 938 further details on the "A" bit and its usage. 940 B 941 Unused (clear on transmit) 943 U 944 This is the Uniqueness bit. This bit aids in duplicate address 945 detection. When this bit is set in an NHRP Resolution Request 946 and one or more entries exist in the NHS cache which meet the 947 requirements of the NHRP Resolution Request then only the CIE in 948 the NHS's cache with this bit set will be returned. Note that 949 even if this bit was set at registration time, there may still be 950 multiple CIEs that might fulfill the NHRP Resolution Request 951 because an entire subnet can be registered through use of the 952 Prefix Length in the CIE and the address of interest might be 953 within such a subnet. If the "uniqueness" bit is set and the 954 responding NHS has one or more cache entries which match the 955 request but no such cache entry has the "uniqueness" bit set, 956 then the NHRP Resolution Reply returns with a NAK code of "13 - 957 Binding Exists But Is Not Unique" and no CIE is included. If a 958 client wishes to receive non- unique Next Hop Entries, then 959 the client must have the "uniqueness" bit set to zero in its NHRP 960 Resolution Request. Note that when this bit is set in an NHRP 961 Registration Request, only a single CIE may be specified in the 962 NHRP Registration Request and that CIE must have the Prefix 963 Length field set to 0xFF. 965 Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP 966 Resolution Request. If one is specified then that entry carries the 967 pertinent information for the client sourcing the NHRP Resolution 968 Request. Usage of the CIE in the NHRP Resolution Request is 969 described below: 971 Prefix Length 972 If a CIE is specified in the NHRP Resolution Request then the 973 Prefix Length field may be used to qualify the widest acceptable 974 prefix which may be used to satisfy the NHRP Resolution Request. 975 In the case of NHRP Resolution Request/Reply, the Prefix Length 976 specifies the equivalence class of addresses which match the 977 first "Prefix Length" bit positions of the Destination Protocol 978 Address. If the "U" bit is set in the common header then this 979 field MUST be set to 0xFF. 981 Maximum Transmission Unit 982 This field gives the maximum transmission unit for the source 983 station. A possible use of this field in the NHRP Resolution 984 Request packet is for the NHRP Resolution Requester to ask for a 985 target MTU. In lieu of that usage, the CIE must be omitted. 987 All other fields in the CIE MUST be ignored and SHOULD be set to 0. 989 The Destination Protocol Address in the common header of the 990 Mandatory Part of this message contains the protocol address of the 991 station for which resolution is desired. An NHC MUST send the NHRP 992 Resolution Request directly to one of its serving NHSs (see Section 3 993 for more information). 995 5.2.2 NHRP Resolution Reply 997 The NHRP Resolution Reply packet has a Type code of 2. CIEs 998 correspond to Next Hop Entries in an NHS's cache which match the 999 criteria in the NHRP Resolution Request. Its mandatory part is coded 1000 as described in Section 5.2.0.1. The message specific meanings of 1001 the fields are as follows: 1003 Flags - The flags field is coded as follows: 1005 0 1 1006 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |Q|A|B|U| unused | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 Q 1012 Copied from the NHRP Resolution Request. Set if the NHRP 1013 Resolution Requester is a router; clear if it is a host. 1015 A 1016 Set if the next hop CIE in the NHRP Resolution Reply is 1017 authoritative; clear if the NHRP Resolution Reply is non- 1018 authoritative. 1020 When an NHS receives a NHRP Resolution Request for authoritative 1021 information for which it is the authoritative source, it MUST 1022 respond with a NHRP Resolution Reply containing all and only 1023 those next hop CIEs which are contained in the NHS's cache which 1024 both match the criteria of the NHRP Resolution Request and are 1025 authoritative cache entries. An NHS is an authoritative source 1026 for a NHRP Resolution Request if the information in the NHS's 1027 cache matches the NHRP Resolution Request criteria and that 1028 information was obtained through a NHRP Registration Request or 1029 through synchronization with an NHS which obtained this 1030 information through a NHRP Registration Request. An 1031 authoritative cache entry is one which is obtained through a NHRP 1032 Registration Request or through synchronization with an NHS which 1033 obtained this information through a NHRP Registration Request. 1035 An NHS obtains non-authoritative CIEs through promiscuous 1036 listening to NHRP packets other than NHRP Registrations which are 1037 directed at it. A NHRP Resolution Request which indicates a 1038 request for non-authoritative information should cause a NHRP 1039 Resolution Reply which contains all entries in the replying NHS's 1040 cache (i.e., both authoritative and non-authoritative) which 1041 match the criteria specified in the request. 1043 B 1044 Set if the association between the destination and the next hop 1045 information is guaranteed to be stable for the lifetime of the 1046 information (the holding time). This is the case if the Next Hop 1047 protocol address identifies the destination (though it may be 1048 different in value than the Destination address if the 1049 destination system has multiple addresses) or if the destination 1050 is not connected directly to the NBMA subnetwork but the egress 1051 router to that destination is guaranteed to be stable (such as 1052 when the destination is immediately adjacent to the egress router 1053 through a non-NBMA interface). This information affects caching 1054 strategies (see section 6.2). 1056 U 1057 This is the Uniqueness bit. See the NHRP Resolution Request 1058 section above for details. When this bit is set only, only one 1059 CIE is included since only one unique binding should exist in an 1060 NHS's cache. 1062 One or more CIEs are specified in the NHRP Resolution Reply. Each CIE 1063 contains NHRP next hop information which the responding NHS has 1064 cached and which matches the parameters specified in the NHRP 1065 Resolution Request. If no match is found by the NHS issuing the NHRP 1066 Resolution Reply then a single CIE is enclosed with the a CIE Code 1067 set appropriately (see below) and all other fields MUST be ignored 1068 and SHOULD be set to 0. In order to facilitate the use of NHRP by 1069 minimal client implementations, the first CIE MUST contain the next 1070 hop with the highest preference value so that such an implementation 1071 need parse only a single CIE. 1073 Code 1074 If this field is set to zero then this packet contains a 1075 positively acknowledged NHRP Resolution Reply. If this field 1076 contains any other value then this message contains an NHRP 1077 Resolution Reply NAK which means that an appropriate 1078 internetworking layer to NBMA address binding was not available 1079 in the responding NHS's cache. If NHRP Resolution Reply contains 1080 a Client Information Entry with a NAK Code other than 0 then it 1081 MUST NOT contain any other CIE. Currently defined NAK Codes are 1082 as follows: 1084 12 - No Internetworking Layer Address to NBMA Address Binding 1085 Exists 1086 This code states that there were absolutely no internetworking 1087 layer address to NBMA address bindings found in the responding 1088 NHS's cache. 1090 13 - Binding Exists But Is Not Unique 1092 This code states that there were one or more internetworking 1093 layer address to NBMA address bindings found in the responding 1094 NHS's cache, however none of them had the uniqueness bit set. 1096 Prefix Length 1097 In the case of NHRP Resolution Reply, the Prefix Length specifies 1098 the equivalence class of addresses which match the first "Prefix 1099 Length" bit positions of the Destination Protocol Address. 1101 Holding Time 1102 The Holding Time specified in a CIE of an NHRP Resolution Reply 1103 is the amount of time remaining before the expiration of the 1104 client information which is cached at the replying NHS. It is 1105 not the value which was registered by the client. 1107 The remainder of the fields for the CIE for each next hop are 1108 filled out as they were defined when the next hop was registered 1109 with the responding NHS (or one of the responding NHS's 1110 synchronized servers) via the NHRP Registration Request. 1112 Load-splitting may be performed when more than one Client Information 1113 Entry is returned to a requester when equal preference values are 1114 specified. Also, the alternative addresses may be used in case of 1115 connectivity failure in the NBMA subnetwork (such as a failed call 1116 attempt in connection-oriented NBMA subnetworks). 1118 Any extensions present in the NHRP Resolution Request packet MUST be 1119 present in the NHRP Resolution Reply even if the extension is non- 1120 Compulsory. 1122 If an unsolicited NHRP Resolution Reply packet is received, an Error 1123 Indication of type Invalid NHRP Resolution Reply Received SHOULD be 1124 sent in response. 1126 When an NHS that serves a given NHC receives an NHRP Resolution Reply 1127 destined for that NHC then the NHS must MUST send the NHRP Resolution 1128 Reply directly to the NHC (see Section 3). 1130 5.2.3 NHRP Registration Request 1132 The NHRP Registration Request is sent from a station to an NHS to 1133 notify the NHS of the station's NBMA information. It has a Type code 1134 of 3. Each CIE corresponds to Next Hop information which is to be 1135 cached at an NHS. The mandatory part of an NHRP Registration Request 1136 is coded as described in Section 5.2.0.1. The message specific 1137 meanings of the fields are as follows: 1139 Flags - The flags field is coded as follows: 1141 0 1 1142 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 |U| unused | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 U 1148 This is the Uniqueness bit. When set in an NHRP Registration 1149 Request, this bit indicates that the registration of the protocol 1150 address is unique within the confines of the set of synchronized 1151 NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC 1152 cache. Any attempt to register a binding between the protocol 1153 address and an NBMA address when this bit is set MUST be rejected 1154 with a Code of "14 - Unique Internetworking Layer Address Already 1155 Registered" if the replying NHS already has a cache entry for the 1156 protocol address and the cache entry has the "uniqueness" bit 1157 set. A registration of a CIE's information is rejected when the 1158 CIE is returned with the Code field set to anything other than 1159 0x00. See the description of the uniqueness bit in NHRP 1160 Resolution Request section above for further details. When this 1161 bit is set only, only one CIE MAY be included in the NHRP 1162 Registration Request. 1164 Request ID 1165 The request ID has the same meaning as described in Section 1166 5.2.0.1. However, the request ID for NHRP Registrations which is 1167 maintained at each client MUST be kept in non-volatile memory so 1168 that when a client crashes and reregisters there will be no 1169 inconsistency in the NHS's database. In order to reduce the 1170 overhead associated with updating non-volatile memory, the actual 1171 updating need not be done with every increment of the Request ID 1172 but could be done, for example, every 50 or 100 increments. In 1173 this scenario, when a client crashes and reregisters it knows to 1174 add 100 to the value of the Request ID in the non-volatile memory 1175 before using the Request ID for subsequent registrations. 1177 One or more CIEs are specified in the NHRP Registration Request. 1178 Each CIE contains next hop information which a client is attempting 1179 to register with its servers. Generally, all fields in CIEs enclosed 1180 in NHRP Registration Requests are coded as described in Section 1181 5.2.0.1. However, if a station is only registering itself with the 1182 NHRP Registration Request then it MAY code the Cli Addr T/L, Cli 1183 SAddr T/L, and Cli Proto Len as zero which signifies that the client 1184 address information is to be taken from the source information in the 1185 common header (see Section 5.2.0.1). Below, further clarification is 1186 given for some fields in a CIE in the context of a NHRP Registration 1187 Request. 1189 Code 1190 This field is set to 0x00 in NHRP Registration Requests. 1192 Prefix Length 1194 This field may be used in a NHRP Registration Request to register 1195 equivalence information for the Client Protocol Address specified 1196 in the CIE of an NHRP Registration Request In the case of NHRP 1197 Registration Request, the Prefix Length specifies the equivalence 1198 class of addresses which match the first "Prefix Length" bit 1199 positions of the Client Protocol Address. If the "U" bit is set 1200 in the common header then this field MUST be set to 0xFF. 1202 The NHRP Registration Request is used to register an NHC's NHRP 1203 information with its NHSs. If an NHC is configured with the protocol 1204 address of a serving NHS then the NHC may place the NHS's protocol 1205 address in the Destination Protocol Address field of the NHRP 1206 Registration Request common header otherwise the NHC must place its 1207 own protocol address in the Destination Protocol Address field. 1209 When an NHS receives an NHRP Registration Request which has the 1210 Destination Protocol Address field set to an address which belongs to 1211 a LIS/LAG for which the NHS is serving then if the Destination 1212 Protocol Address field is equal to the Source Protocol Address field 1213 (which would happen if the NHC put its protocol address in the 1214 Destination Protocol Address) or the Destination Protocol Address 1215 field is equal to the protocol address of the NHS then the NHS 1216 processes the NHRP Registration Request after doing appropriate error 1217 checking (including any applicable policy checking). 1219 When an NHS receives an NHRP Registration Request which has the 1220 Destination Protocol Address field set to an address which does not 1221 belong to a LIS/LAG for which the NHS is serving then the NHS 1222 forwards the packet down the routed path toward the appropriate 1223 LIS/LAG. 1225 When an NHS receives an NHRP Registration Request which has the 1226 Destination Protocol Address field set to an address which belongs to 1227 a LIS/LAG for which the NHS is serving then if the Destination 1228 Protocol Address field does not equal the Source Protocol Address 1229 field and the Destination Protocol Address field does not equal the 1230 protocol address of the NHS then the NHS forwards the message to the 1231 appropriate NHS within the LIS/LAG as specified by Destination 1232 Protocol Address field. 1234 It is possible that a misconfigured station will attempt to register 1235 with the wrong NHS (i.e., one that cannot serve it due to policy 1236 constraints or routing state). If this is the case, the NHS MUST 1237 reply with a NAK-ed Registration Reply of type Can't Serve This 1238 Address. 1240 If an NHS cannot serve a station due to a lack of resources, the NHS 1241 MUST reply with a NAK-ed Registration Reply of type Registration 1242 Overflow. 1244 In order to keep the registration entry from being discarded, the 1245 station MUST re-send the NHRP Registration Request packet often 1246 enough to refresh the registration, even in the face of occasional 1247 packet loss. It is recommended that the NHRP Registration Request 1248 packet be sent at an interval equal to one-third of the Holding Time 1249 specified therein. 1251 5.2.4 NHRP Registration Reply 1253 The NHRP Registration Reply is sent by an NHS to a client in response 1254 to that client's NHRP Registration Request. If the Code field of a 1255 CIE in the NHRP Registration Reply has anything other than 0 zero in 1256 it then the NHRP Registration Reply is a NAK otherwise the reply is 1257 an ACK. The NHRP Registration Reply has a Type code of 4. 1259 An NHRP Registration Reply is formed from an NHRP Registration 1260 Request by changing the type code to 4, updating the CIE Code field, 1261 and filling in the appropriate extensions if they exist. The message 1262 specific meanings of the fields are as follows: 1264 Attempts to register the information in the CIEs of an NHRP 1265 Registration Request may fail for various reasons. If this is the 1266 case then each failed attempt to register the information in a CIE of 1267 an NHRP Registration Request is logged in the associated NHRP 1268 Registration Reply by setting the CIE Code field to the appropriate 1269 error code as shown below: 1271 CIE Code 1273 0 - Successful Registration 1274 The information in the CIE was successfully registered with the 1275 NHS. 1277 4 - Can't Serve This Address 1279 An NHS may refuse an NHRP Registration Request attempt for 1280 administrative reasons (due to policy constraints or routing 1281 state). If so, the NHS MUST send an NHRP Registration Reply 1282 which contains a NAK code of 4. 1284 5 - Registration Overflow 1286 If an NHS cannot serve a station due to a lack of resources, 1287 the NHS MUST reply with a NAKed NHRP Registration Reply which 1288 contains a NAK code of 5. 1290 14 - Unique Internetworking Layer Address Already Registered 1291 If a client tries to register a protocol address to NBMA 1292 address binding with the uniqueness bit on and the protocol 1293 address already exists in the NHS's cache then if that cache 1294 entry also has the uniqueness bit on then this NAK Code is 1295 returned in the CIE in the NHRP Registration Reply. 1297 Due to the possible existence of asymmetric routing, an NHRP 1298 Registration Reply may not be able to merely follow the routed path 1299 back to the source protocol address specified in the common header of 1300 the NHRP Registration Reply. As a result, there MUST exist a direct 1301 NBMA level connection between the NHC and its NHS on which to send 1302 the NHRP Registration Reply before NHRP Registration Reply may be 1303 returned to the NHC. If such a connection does not exist then the 1304 NHS must setup such a connection to the NHC by using the source NBMA 1305 information supplied in the common header of the NHRP Registration 1306 Request. 1308 5.2.5 NHRP Purge Request 1310 The NHRP Purge Request packet is sent in order to invalidate cached 1311 information in a station. The NHRP Purge Request packet has a type 1312 code of 5. The mandatory part of an NHRP Purge Request is coded as 1313 described in Section 5.2.0.1. The message specific meanings of the 1314 fields are as follows: 1316 Flags - The flags field is coded as follows: 1318 0 1 1319 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 |N| unused | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 N 1325 When set, this bit tells the receiver of the NHRP Purge Request 1326 that the requester does not expect to receive an NHRP Purge 1327 Reply. If an unsolicited NHRP Purge Reply is received by a 1328 station where that station is identified in the Source Protocol 1329 Address of the packet then that packet must be ignored. 1331 One or more CIEs are specified in the NHRP Purge Request. Each CIE 1332 contains next hop information which is to be purged from an NHS/NHC 1333 cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests 1334 are coded as described in Section 5.2.0.1. Below, further 1335 clarification is given for some fields in a CIE in the context of a 1336 NHRP Purge Request. 1338 Code 1339 This field is set to 0x00 in NHRP Purge Requests. 1341 Prefix Length 1343 In the case of NHRP Purge Requests, the Prefix Length specifies 1344 the equivalence class of addresses which match the first "Prefix 1345 Length" bit positions of the Client Protocol Address specified in 1346 the CIE. All next hop information which contains a protocol 1347 address which matches an element of this equivalence class is to 1348 be purged from the receivers cache. 1350 The Maximum Transmission Unit and Preference fields of the CIE are 1351 coded as zero. The Holding Time should be coded as zero but there 1352 may be some utility in supplying a "short" holding time to be 1353 applied to the matching next hop information before that 1354 information would be purged; this usage is for further study. The 1355 Client Protocol Address field and the Cli Proto Len field MUST be 1356 filled in. The Client Protocol Address is filled in with the 1357 protocol address to be purged from the receiving station's cache 1358 while the Cli Proto Len is set the length of the purged client's 1359 protocol address. All remaining fields in the CIE MAY be set to 1360 zero although the client NBMA information (and associated length 1361 fields) MAY be specified to narrow the scope of the NHRP Purge 1362 Request if requester desires. However, the receiver of an NHRP 1363 Purge Request may choose to ignore the Client NBMA information if 1364 it is supplied. 1366 An NHRP Purge Request packet is sent from an NHS to a station to 1367 cause it to delete previously cached information. This is done when 1368 the information may be no longer valid (typically when the NHS has 1369 previously provided next hop information for a station that is not 1370 directly connected to the NBMA subnetwork, and the egress point to 1371 that station may have changed). 1373 An NHRP Purge Request packet may also be sent from an NHC to an NHS 1374 with which the NHC had previously registered. This allows for an NHC 1375 to invalidate its registration with NHRP before it would otherwise 1376 expire via the holding timer. If an NHC does not have knowledge of a 1377 protocol address of a serving NHS then the NHC must place its own 1378 protocol address in the Destination Protocol Address field and 1379 forward the packet along the routed path. Otherwise, the NHC must 1380 place the protocol address of a serving NHS in this field. 1382 Serving NHSs may need to send one or more new NHRP Purge Requests as 1383 a result of receiving a purge from one of their served NHCs since the 1384 NHS may have previously responded to NHRP Resolution Requests for 1385 that NHC's NBMA information. These purges are "new" in that they are 1386 sourced by the NHS and not the NHC; that is, for each NHC that 1387 previously sent a NHRP Resolution Request for the purged NHC NBMA 1388 information, an NHRP Purge Request is sent which contains the Source 1389 Protocol/NBMA Addresses of the NHS and the Destination Protocol 1390 Address of the NHC which previously sent an NHRP Resolution Request 1391 prior to the purge. 1393 The station sending the NHRP Purge Request MAY periodically 1394 retransmit the NHRP Purge Request until either NHRP Purge Request is 1395 acknowledged or until the holding time of the information being 1396 purged has expired. Retransmission strategies for NHRP Purge 1397 Requests are a local matter. 1399 When a station receives an NHRP Purge Request, it MUST discard any 1400 previously cached information that matches the information in the 1401 CIEs. 1403 An NHRP Purge Reply MUST be returned for the NHRP Purge Request even 1404 if the station does not have a matching cache entry assuming that the 1405 "N" bit is off in the NHRP Purge Request. 1407 If the station wishes to reestablish communication with the 1408 destination shortly after receiving an NHRP Purge Request, it should 1409 make an authoritative NHRP Resolution Request in order to avoid any 1410 stale cache entries that might be present in intermediate NHSs (See 1411 section 6.2.2.). It is recommended that authoritative NHRP 1412 Resolution Requests be made for the duration of the holding time of 1413 the old information. 1415 5.2.6 NHRP Purge Reply 1417 The NHRP Purge Reply packet is sent in order to assure the sender of 1418 an NHRP Purge Request that all cached information of the specified 1419 type has been purged from the station sending the reply. The NHRP 1420 Purge Reply has a type code of 6. 1422 An NHRP Purge Reply is formed from an NHRP Purge Request by merely 1423 changing the type code in the request to 6. The packet is then 1424 returned to the requester after filling in the appropriate extensions 1425 if they exist. 1427 5.2.7 NHRP Error Indication 1429 The NHRP Error Indication is used to convey error indications to the 1430 sender of an NHRP packet. It has a type code of 7. The Mandatory 1431 Part has the following format: 1433 0 1 2 3 1434 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 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Src Proto Len | Dst Proto Len | unused | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Error Code | Error Offset | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Source NBMA Address (variable length) | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Source NBMA Subaddress (variable length) | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Source Protocol Address (variable length) | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Destination Protocol Address (variable length) | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Contents of NHRP Packet in error (variable length) | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 Src Proto Len 1452 This field holds the length in octets of the Source Protocol 1453 Address. 1455 Dst Proto Len 1456 This field holds the length in octets of the Destination Protocol 1457 Address. 1459 Error Code 1460 An error code indicating the type of error detected, chosen from 1461 the following list: 1463 1 - Unrecognized Extension 1465 When the Compulsory bit of an extension in NHRP packet is set, 1466 the NHRP packet cannot be processed unless the extension has 1467 been processed. The responder MUST return an NHRP Error 1468 Indication of type Unrecognized Extension if it is incapable of 1469 processing the extension. However, if a transit NHS (one which 1470 is not going to generate a reply) detects an unrecognized 1471 extension, it SHALL ignore the extension. 1473 3 - NHRP Loop Detected 1475 A Loop Detected error is generated when it is determined that 1476 an NHRP packet is being forwarded in a loop. 1478 6 - Protocol Address Unreachable 1480 This error occurs when a packet it moving along the routed path 1481 and it reaches a point such that the protocol address of 1482 interest is not reachable. 1484 7 - Protocol Error 1486 A generic packet processing error has occurred (e.g., invalid 1487 version number, invalid protocol type, failed checksum, etc.) 1489 8 - NHRP SDU Size Exceeded 1491 If the SDU size of the NHRP packet exceeds the MTU size of the 1492 NBMA network then this error is returned. 1494 9 - Invalid Extension 1496 If an NHS finds an extension in a packet which is inappropriate 1497 for the packet type, an error is sent back to the sender with 1498 Invalid Extension as the code. 1500 10 - Invalid NHRP Resolution Reply Received 1502 If a client receives a NHRP Resolution Reply for a Next Hop 1503 Resolution Request which it believes it did not make then an 1504 error packet is sent to the station making the reply with an 1505 error code of Invalid Reply Received. 1507 11 - Authentication Failure 1509 If a received packet fails an authentication test then this 1510 error is returned. 1512 15 - Hop Count Exceeded 1514 The hop count which was specified in the Fixed Header of an 1515 NHRP message has been exceeded. 1517 Error Offset 1518 The offset in octets into the NHRP packet, starting at the NHRP 1519 Fixed Header, at which the error was detected. 1521 Source NBMA Address 1522 The Source NBMA address field is the address of the station which 1523 observed the error. 1525 Source NBMA SubAddress 1526 The Source NBMA subaddress field is the address of the station 1527 which observed the error. If the field's length as specified in 1528 ar$sstl is 0 then no storage is allocated for this address at all. 1530 Source Protocol Address 1531 This is the protocol address of the station which issued the Error 1532 packet. 1534 Destination Protocol Address 1535 This is the protocol address of the station which sent the packet 1536 which was found to be in error. 1538 An NHRP Error Indication packet SHALL NEVER be generated in response 1539 to another NHRP Error Indication packet. When an NHRP Error 1540 Indication packet is generated, the offending NHRP packet SHALL be 1541 discarded. In no case should more than one NHRP Error Indication 1542 packet be generated for a single NHRP packet. 1544 If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA 1545 and Source Protocol address fields of a transiting NHRP Error 1546 Indication packet then the NHS will quietly drop the packet and do 1547 nothing (this scenario would occur when the NHRP Error Indication 1548 packet was itself in a loop). 1550 Note that no extensions may be added to an NHRP Error Indication. 1552 5.3 Extensions Part 1554 The Extensions Part, if present, carries one or more extensions in 1555 {Type, Length, Value} triplets. 1557 Extensions have the following format: 1559 0 1 2 3 1560 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 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 |C|u| Type | Length | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | Value... | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 C 1568 "Compulsory." If clear, and the NHS does not recognize the type 1569 code, the extension may safely be ignored. If set, and the NHS 1570 does not recognize the type code, the NHRP "request" is considered 1571 to be in error. (See below for details.) 1573 u 1574 Unused and must be set to zero. 1576 Type 1577 The extension type code (see below). The extension type is not 1578 qualified by the Compulsory bit, but is orthogonal to it. 1580 Length 1581 The length in octets of the value (not including the Type and 1582 Length fields; a null extension will have only an extension header 1583 and a length of zero). 1585 When extensions exist, the extensions list is terminated by the Null 1586 TLV, having Type = 0 and Length = 0. 1588 Extensions may occur in any order (see Section 5.3.4 for the 1589 exception), but any particular extension type may occur only once in 1590 an NHRP packet with the exception of the Vendor Private extension. 1591 The vendor-private extension may occur multiple times in a packet in 1592 order to allow for extensions which do not share the same vendor ID 1593 to be represented. It is RECOMMENDED that a given vendor include no 1594 more than one Vendor Private Extension. 1596 An NHS MUST NOT change the order of extensions. That is, the order 1597 of extensions placed in an NHRP packet by an NHC (or by an NHS when 1598 an NHS sources a packet) MUST be preserved as the packet moves 1599 between NHSs. Minimal NHC implementations MUST only recognize, but 1600 not necessarily parse, the Vendor Private extension and the End Of 1601 Extensions extension. Extensions are only present in a "reply" if 1602 they were present in the corresponding "request" with the exception 1603 of Vendor Private extensions. The previous statement is not intended 1604 to preclude the creation of NHS-only extensions which might be added 1605 to and removed from NHRP packets by the same NHS; such extensions 1606 MUST not be propagated to NHCs. 1608 The Compulsory bit provides for a means to add to the extension set. 1609 If the bit is set, the NHRP message cannot be properly processed by 1610 the station responding to the message (e.g., the station that would 1611 issue a NHRP Resolution Reply in response to a NHRP Resolution 1612 Request) without processing the extension. As a result, the 1613 responder MUST return an NHRP Error Indication of type Unrecognized 1614 Extension. If the Compulsory bit is clear then the extension can be 1615 safely ignored; however, if an ignored extension is in a "request" 1616 then it MUST be returned, unchanged, in the corresponding "reply" 1617 packet type. 1619 If a transit NHS (one which is not going to generate a "reply") 1620 detects an unrecognized extension, it SHALL ignore the extension. If 1621 the Compulsory bit is set, the transit NHS MUST NOT cache the 1622 information contained in the packet and MUST NOT identify itself as 1623 an egress router (in the Forward Record or Reverse Record 1624 extensions). Effectively, this means, if a transit NHS encounters an 1625 extension which it cannot process and which has the Compulsory bit 1626 set then that NHS MUST NOT participate in any way in the protocol 1627 exchange other than acting as a forwarding agent. 1629 Use of NHRP extension Types in the range 8192 to 16383 are reserved 1630 for research or use in other protocol development and will be 1631 administered by IANA. 1633 5.3.0 The End Of Extensions 1635 Compulsory = 1 1636 Type = 0 1637 Length = 0 1639 When extensions exist, the extensions list is terminated by the End 1640 Of Extensions/Null TLV. 1642 5.3.1 Responder Address Extension 1644 Compulsory = 1 1645 Type = 3 1646 Length = variable 1648 This extension is used to determine the address of the NHRP 1649 responder; i.e., the entity that generates the appropriate "reply" 1650 packet for a given "request" packet. In the case of an NHRP 1651 Resolution Request, the station responding may be different (in the 1652 case of cached replies) than the system identified in the Next Hop 1653 field of the NHRP Resolution Reply. Further, this extension may aid 1654 in detecting loops in the NHRP forwarding path. 1656 This extension uses a single CIE with the extension specific meanings 1657 of the fields set as follows: 1659 The Prefix Length fields MUST be set to 0 and ignored. 1661 CIE Code 1662 16 - Insufficient Resources Exist To Setup Cut-Through 1663 If the responder to an NHRP Resolution Request is an egress point 1664 for the target of the address resolution request (i.e., it is one 1665 of the stations identified in the list of CIEs in an NHRP 1666 Resolution Reply) and the Responder Address extension is included 1667 in the NHRP Resolution Request and insufficient resources to 1668 setup a cut-through VC exist at the responder then the Code field 1669 of the Responder Address Extension is set to 16 decimal in order 1670 to tell the client that a VC setup attempt would in all 1671 likelihood be rejected; otherwise this field MUST be coded as a 1672 zero. NHCs MAY use this field to influence whether they attempt 1673 to setup a cut-through to the egress router. 1675 Maximum Transmission Unit 1676 This field gives the maximum transmission unit preferred by the 1677 responder. If this value is 0 then either the default MTU is used 1678 or the MTU negotiated via signaling is used if such negotiation is 1679 possible for the given NBMA. 1681 Holding Time 1682 The Holding Time field specifies the number of seconds for which 1683 the NBMA information of the responser is considered to be valid. 1684 Cached information SHALL be discarded when the holding time 1685 expires. 1687 "Client Address" information is actually "Responder Address" 1688 information for this extension. Thus, for example, Cli Addr T/L is 1689 the responder NBMA address type and length field. 1691 If a "requester" desires this information, the "requester" SHALL 1692 include this extension with a value of zero. Note that this implies 1693 that no storage is allocated for the Holding Time and Type/Length 1694 fields until the "Value" portion of the extension is filled out. 1696 If an NHS is generating a "reply" packet in response to a "request" 1697 containing this extension, the NHS SHALL include this extension, 1698 containing its protocol address in the "reply". If an NHS has more 1699 than one protocol address, it SHALL use the same protocol address 1700 consistently in all of the Responder Address, Forward Transit NHS 1701 Record, and Reverse Transit NHS Record extensions. The choice of 1702 which of several protocol address to include in this extension is a 1703 local matter. 1705 If an NHRP Resolution Reply packet being forwarded by an NHS contains 1706 a protocol address of that NHS in the Responder Address Extension 1707 then that NHS SHALL generate an NHRP Error Indication of type "NHRP 1708 Loop Detected" and discard the NHRP Resolution Reply. 1710 If an NHRP Resolution Reply packet is being returned by an 1711 intermediate NHS based on cached data, it SHALL place its own address 1712 in this extension (differentiating it from the address in the Next 1713 Hop field). 1715 5.3.2 NHRP Forward Transit NHS Record Extension 1717 Compulsory = 1 1718 Type = 4 1719 Length = variable 1721 The NHRP Forward Transit NHS record contains a list of transit NHSs 1722 through which a "request" has traversed. Each NHS SHALL append to 1723 the extension a Forward Transit NHS element (as specified below) 1724 containing its Protocol address The extension length field and the 1725 ar$chksum fields SHALL be adjusted appropriately. 1727 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1728 this extension. 1730 In addition, NHSs that are willing to act as egress routers for 1731 packets from the source to the destination SHALL include information 1732 about their NBMA Address. 1734 This extension uses a single CIE with the extension specific meanings 1735 of the fields set as follows: 1737 The Prefix Length fields MUST be set to 0 and ignored. 1739 CIE Code 1740 16 - Insufficient Resources Exist To Setup Cut-Through 1741 If an NHRP Resolution Request contains an NHRP Forward Transit 1742 NHS Record Extension and insufficient resources to setup a cut- 1743 through VC exist at the current transit NHS then the CIE Code 1744 field for NHRP Forward Transit NHS Record Extension is set to 16 1745 decimal in order to tell the client that a VC setup attempt would 1746 in all likelihood be rejected; otherwise this field MUST be coded 1747 as a zero. NHCs MAY use this field to influence whether they 1748 attempt to setup a cut-through as described in Section 2.2. Note 1749 that the NHRP Reverse Transit NHS Record Extension MUST always 1750 have this field set to zero. 1752 Maximum Transmission Unit 1753 This field gives the maximum transmission unit preferred by the 1754 transit NHS. If this value is 0 then either the default MTU is 1755 used or the MTU negotiated via signaling is used if such 1756 negotiation is possible for the given NBMA. 1758 Holding Time 1759 The Holding Time field specifies the number of seconds for which 1760 the NBMA information of the transit NHS is considered to be valid. 1761 Cached information SHALL be discarded when the holding time 1762 expires. 1764 "Client Address" information is actually "Forward Transit NHS 1765 Address" information for this extension. Thus, for example, Cli Addr 1766 T/L is the transit NHS NBMA address type and length field. 1768 If a "requester" wishes to obtain this information, it SHALL include 1769 this extension with a length of zero. Note that this implies that no 1770 storage is allocated for the Holding Time and Type/Length fields 1771 until the "Value" portion of the extension is filled out. 1773 If an NHS has more than one Protocol address, it SHALL use the same 1774 Protocol address consistently in all of the Responder Address, 1775 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1776 which of several Protocol addresses to include in this extension is a 1777 local matter. 1779 If a "request" that is being forwarded by an NHS contains the 1780 Protocol Address of that NHS in one of the Forward Transit NHS 1781 elements then the NHS SHALL generate an NHRP Error Indication of type 1782 "NHRP Loop Detected" and discard the "request". 1784 5.3.3 NHRP Reverse Transit NHS Record Extension 1786 Compulsory = 1 1787 Type = 5 1788 Length = variable 1790 The NHRP Reverse Transit NHS record contains a list of transit NHSs 1791 through which a "reply" has traversed. Each NHS SHALL append a 1792 Reverse Transit NHS element (as specified below) containing its 1793 Protocol address to this extension. The extension length field and 1794 ar$chksum SHALL be adjusted appropriately. 1796 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1797 this extension. 1799 In addition, NHSs that are willing to act as egress routers for 1800 packets from the source to the destination SHALL include information 1801 about their NBMA Address. 1803 This extension uses a single CIE with the extension specific meanings 1804 of the fields set as follows: 1806 The CIE Code and Prefix Length fields MUST be set to 0 and ignored. 1808 Maximum Transmission Unit 1809 This field gives the maximum transmission unit preferred by the 1810 transit NHS. If this value is 0 then either the default MTU is 1811 used or the MTU negotiated via signaling is used if such 1812 negotiation is possible for the given NBMA. 1814 Holding Time 1815 The Holding Time field specifies the number of seconds for which 1816 the NBMA information of the transit NHS is considered to be valid. 1817 Cached information SHALL be discarded when the holding time 1818 expires. 1820 "Client Address" information is actually "Reverse Transit NHS 1821 Address" information for this extension. Thus, for example, Cli Addr 1822 T/L is the transit NHS NBMA address type and length field. 1824 If a "requester" wishes to obtain this information, it SHALL include 1825 this extension with a length of zero. Note that this implies that no 1826 storage is allocated for the Holding Time and Type/Length fields 1827 until the "Value" portion of the extension is filled out. 1829 If an NHS has more than one Protocol address, it SHALL use the same 1830 Protocol address consistently in all of the Responder Address, 1831 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1832 which of several Protocol addresses to include in this extension is a 1833 local matter. 1835 If a "reply" that is being forwarded by an NHS contains the Protocol 1836 Address of that NHS in one of the Reverse Transit NHS elements then 1837 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop 1838 Detected" and discard the "reply". 1840 Note that this information may be cached at intermediate NHSs; if 1841 so, the cached value SHALL be used when generating a reply. 1843 5.3.4 NHRP Authentication Extension 1845 Compulsory = 1 1846 Type = 7 1847 Length = variable 1849 The NHRP Authentication Extension is carried in NHRP packets to 1850 convey authentication information between NHRP speakers. The 1851 Authentication Extension may be included in any NHRP "request" or 1852 "reply" only. 1854 Except in the case of an NHRP Registration Request/Reply 1855 Authentication is done pairwise on an NHRP hop-by-hop basis; i.e., 1856 the authentication extension is regenerated at each hop. In the case 1857 of an NHRP Registration Request/Reply, the Authentication is checked 1858 on an end-to-end basis rather than hop-by-hop. If a received packet 1859 fails the authentication test, the station SHALL generate an Error 1860 Indication of type "Authentication Failure" and discard the packet. 1861 Note that one possible authentication failure is the lack of an 1862 Authentication Extension; the presence or absence of the 1863 Authentication Extension is a local matter. 1865 0 1 2 3 1866 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 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Authentication Type | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | | 1871 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1872 | | 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 The Authentication Type field identifies the authentication method in 1876 use. Currently assigned values are: 1878 1 - Cleartext Password 1879 2 - Keyed MD5 1881 All other values are reserved. 1883 The Authentication Data field contains the type-specific 1884 authentication information. 1886 In the case of Cleartext Password Authentication, the Authentication 1887 Data consists of a variable length password. 1889 In the case of Keyed MD5 Authentication, the Authentication Data 1890 contains the 16 byte MD5 digest of the entire NHRP packet, including 1891 the encapsulated protocol's header, with the authentication key 1892 appended to the end of the packet. The authentication key is not 1893 transmitted with the packet. The MD5 digest covers only the 1894 following fields of the NHRP packet: fixed part (with hop count, 1895 packet size and checksum being set to zero), mandatory part, 1896 Responder Address extension, and authentication extension. Note that 1897 when MD5 is used, there is an explicit ordering of the extensions 1898 such that: if the Responder Address extension exists then it MUST be 1899 the first extension in the packet and the Authentication Extension 1900 MUST be the second extension otherwise the Authentication Extension 1901 MUST be the first extension in the packet. 1903 Distribution of authentication keys is outside the scope of this 1904 document. 1906 5.3.5 NHRP Vendor-Private Extension 1908 Compulsory = 0 1909 Type = 8 1910 Length = variable 1912 The NHRP Vendor-Private Extension is carried in NHRP packets to 1913 convey vendor-private information or NHRP extensions between NHRP 1914 speakers. 1916 0 1 2 3 1917 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 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Vendor ID | Data.... | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 Vendor ID 1923 802 Vendor ID as assigned by the IEEE [6] 1925 Data 1926 The remaining octets after the Vendor ID in the payload are 1927 vendor-dependent data. 1929 This extension may be added to any "request" or "reply" packet and it 1930 is the only extension that may be included multiple times. If the 1931 receiver does not handle this extension, or does not match the Vendor 1932 ID in the extension then the extension may be completely ignored by 1933 the receiver. If a Vendor Private Extension is included in a 1934 "request" then is must be copied in the corresponding "reply". 1936 6. Protocol Operation 1938 In this section, we discuss certain operational considerations of 1939 NHRP. 1941 6.1 Router-to-Router Operation 1943 In practice, the initiating and responding stations may be either 1944 hosts or routers. However, there is a possibility under certain 1945 conditions that a stable routing loop may occur if NHRP is used 1946 between two routers. In particular, attempting to establish an NHRP 1947 path across a boundary where information used in route selection is 1948 lost may result in a routing loop. Such situations include the loss 1949 of BGP path vector information, the interworking of multiple routing 1950 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 1951 circumstances, NHRP should not be used. This situation can be 1952 avoided if there are no "back door" paths between the entry and 1953 egress router outside of the NBMA subnetwork. Protocol mechanisms to 1954 relax these restrictions are under investigation. 1956 In general it is preferable to use mechanisms, if they exist, in 1957 routing protocols to resolve the egress point when the destination 1958 lies outside of the NBMA subnetwork, since such mechanisms will be 1959 more tightly coupled to the state of the routing system and will 1960 probably be less likely to create loops. 1962 6.2 Cache Management Issues 1964 The management of NHRP caches in the source station, the NHS serving 1965 the destination, and any intermediate NHSs is dependent on a number 1966 of factors. 1968 6.2.1 Caching Requirements 1970 Source Stations 1972 Source stations MUST cache all received NHRP Resolution Replies that 1973 they are actively using. They also must cache "incomplete" entries, 1974 i.e., those for which a NHRP Resolution Request has been sent but 1975 which a NHRP Resolution Reply has not been received. This is 1976 necessary in order to preserve the Request ID for retries, and 1977 provides the state necessary to avoid triggering NHRP Resolution 1978 Requests for every data packet sent to the destination. 1980 Source stations MUST purge expired information from their caches. 1981 Source stations MUST purge the appropriate cached information upon 1982 receipt of an NHRP Purge Request packet. 1984 When a station has a co-resident client and NHS, the station may 1985 reply to NHRP Resolution Requests with information which the station 1986 cached as a result of the station making its own NHRP Resolution 1987 Requests and receiving its own NHRP Resolution Replies as long as the 1988 station follows the rules for Transit NHSs as seen below. 1990 Serving NHSs 1992 The NHS serving the destination (the one which responds 1993 authoritatively to NHRP Resolution Requests) SHOULD cache information 1994 about all NHRP Resolution Requests to which it has responded if the 1995 information in the NHRP Resolution Reply has the possibility of 1996 changing during its lifetime (so that an NHRP Purge Request packet 1997 can be issued). The NBMA information provided by the source station 1998 in the NHRP Resolution Request may be cached for the duration of its 1999 holding time. This information is considered to be stable, since it 2000 identifies a station directly attached to the NBMA subnetwork. An 2001 example of unstable information is NBMA information derived from a 2002 routing table, where that routing table information has not been 2003 guaranteed to be stable through administrative means. 2005 Transit NHSs 2007 A Transit NHS (lying along the NHRP path between the source station 2008 and the responding NHS) may cache information contained in NHRP 2009 Resolution Request packets that it forwards. A Transit NHS may cache 2010 information contained in NHRP Resolution Reply packets that it 2011 forwards only if that NHRP Resolution Reply has the Stable (B) bit 2012 set. It MUST discard any cached information whose holding time has 2013 expired. It may return cached information in response to non- 2014 authoritative NHRP Resolution Requests only. 2016 6.2.2 Dynamics of Cached Information 2018 NBMA-Connected Destinations 2020 NHRP's most basic function is that of simple NBMA address 2021 resolution of stations directly attached to the NBMA subnetwork. 2022 These mappings are typically very static, and appropriately chosen 2023 holding times will minimize problems in the event that the NBMA 2024 address of a station must be changed. Stale information will cause 2025 a loss of connectivity, which may be used to trigger an 2026 authoritative NHRP Resolution Request and bypass the old data. In 2027 the worst case, connectivity will fail until the cache entry times 2028 out. 2030 This applies equally to information marked in NHRP Resolution 2031 Replies as being "stable" (via the "B" bit). 2033 This also applies equally well to source stations that are routers 2034 as well as those which are hosts. 2036 Note that the information carried in the NHRP Resolution Request 2037 packet is always considered "stable" because it represents a 2038 station that is directly connected to the NBMA subnetwork. 2040 Destinations Off of the NBMA Subnetwork 2042 If the source of a NHRP Resolution Request is a host and the 2043 destination is not directly attached to the NBMA subnetwork, and 2044 the route to that destination is not considered to be "stable," the 2045 destination mapping may be very dynamic (except in the case of a 2046 subnetwork where each destination is only singly homed to the NBMA 2047 subnetwork). As such the cached information may very likely become 2048 stale. The consequence of stale information in this case will be a 2049 suboptimal path (unless the internetwork has partitioned or some 2050 other routing failure has occurred). 2052 6.3 Use of the Prefix Length field of a CIE 2054 A certain amount of care needs to be taken when using the Prefix 2055 Length field of a CIE, in particular with regard to the prefix length 2056 advertised (and thus the size of the equivalence class specified by 2057 it). Assuming that the routers on the NBMA subnetwork are exchanging 2058 routing information, it should not be possible for an NHS to create a 2059 black hole by advertising too large of a set of destinations, but 2060 suboptimal routing (e.g., extra internetwork layer hops through the 2061 NBMA) can result. To avoid this situation an NHS that wants to send 2062 the Prefix Length MUST obey the following rule: 2064 The NHS examines the Network Layer Reachability Information (NLRI) 2065 associated with the route that the NHS would use to forward towards 2066 the destination (as specified by the Destination internetwork layer 2067 address in the NHRP Resolution Request), and extracts from this 2068 NLRI the shortest address prefix such that: (a) the Destination 2069 internetwork layer address (from the NHRP Resolution Request) is 2070 covered by the prefix, (b) the NHS does not have any routes with 2071 NLRI that forms a subset of what is covered by the prefix. The 2072 prefix may then be used in the CIE. 2074 The Prefix Length field of the CIE should be used with restraint, in 2075 order to avoid NHRP stations choosing suboptimal transit paths when 2076 overlapping prefixes are available. This document specifies the use 2077 of the prefix length only when all the destinations covered by the 2078 prefix are "stable". That is, either: 2080 (a) All destinations covered by the prefix are on the NBMA network, or 2082 (b) All destinations covered by the prefix are directly attached to 2083 the NHRP responding station. 2085 Use of the Prefix Length field of the CIE in other circumstances is 2086 outside the scope of this document. 2088 6.4 Domino Effect 2090 One could easily imagine a situation where a router, acting as an 2091 ingress station to the NBMA subnetwork, receives a data packet, such 2092 that this packet triggers an NHRP Resolution Request. If the router 2093 forwards this data packet without waiting for an NHRP transit path to 2094 be established, then when the next router along the path receives the 2095 packet, the next router may do exactly the same - originate its own 2096 NHRP Resolution Request (as well as forward the packet). In fact 2097 such a data packet may trigger NHRP Resolution Request generation at 2098 every router along the path through an NBMA subnetwork. We refer to 2099 this phenomena as the NHRP "domino" effect. 2101 The NHRP domino effect is clearly undesirable. At best it may result 2102 in excessive NHRP traffic. At worst it may result in an excessive 2103 number of virtual circuits being established unnecessarily. 2104 Therefore, it is important to take certain measures to avoid or 2105 suppress this behavior. NHRP implementations for NHSs MUST provide a 2106 mechanism to address this problem. One possible strategy to address 2107 this problem would be to configure a router in such a way that NHRP 2108 Resolution Request generation by the router would be driven only by 2109 the traffic the router receives over its non-NBMA interfaces 2110 (interfaces that are not attached to an NBMA subnetwork). Traffic 2111 received by the router over its NBMA-attached interfaces would not 2112 trigger NHRP Resolution Requests. Such a router avoids the NHRP 2113 domino effect through administrative means. 2115 7. NHRP over Legacy BMA Networks 2117 There would appear to be no significant impediment to running NHRP 2118 over legacy broadcast subnetworks. There may be issues around 2119 running NHRP across multiple subnetworks. Running NHRP on broadcast 2120 media has some interesting possibilities; especially when setting up 2121 a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both 2122 end stations are legacy attached. This use for NHRP requires further 2123 research. 2125 8. Security Considerations 2127 As in any resolution protocol, there are a number of potential 2128 security attacks possible. Plausible examples include denial-of- 2129 service attacks, and masquerade attacks using register and purge 2130 packets. The use of authentication on all packets is recommended to 2131 avoid such attacks. 2133 The authentication schemes described in this document are intended to 2134 allow the receiver of a packet to validate the identity of the 2135 sender; they do not provide privacy or protection against replay 2136 attacks. 2138 Detailed security analysis of this protocol is for further study. 2140 9. Discussion 2142 The result of an NHRP Resolution Request depends on how routing is 2143 configured among the NHSs of an NBMA subnetwork. If the destination 2144 station is directly connected to the NBMA subnetwork and the the 2145 routed path to it lies entirely within the NBMA subnetwork, the NHRP 2146 Resolution Replies always return the NBMA address of the destination 2147 station itself rather than the NBMA address of some egress router. 2148 On the other hand, if the routed path exits the NBMA subnetwork, NHRP 2149 will be unable to resolve the NBMA address of the destination, but 2150 rather will return the address of the egress router. For 2151 destinations outside the NBMA subnetwork, egress routers and routers 2152 in the other subnetworks should exchange routing information so that 2153 the optimal egress router may be found. 2155 In addition to NHSs, an NBMA station could also be associated with 2156 one or more regular routers that could act as "connectionless 2157 servers" for the station. The station could then choose to resolve 2158 the NBMA next hop or just send the packets to one of its 2159 connectionless servers. The latter option may be desirable if 2160 communication with the destination is short-lived and/or doesn't 2161 require much network resources. The connectionless servers could, of 2162 course, be physically integrated in the NHSs by augmenting them with 2163 internetwork layer switching functionality. 2165 References 2167 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 2168 Govindan, RFC1735. 2170 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 2172 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 2174 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 2175 and D. Piscitello, RFC 1209. 2177 [5] Protocol Identification in the Network Layer, ISO/IEC TR 2178 9577:1990. 2180 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 2182 [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, 2183 RFC1483. 2185 [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, 2186 A. Malis, D. Robinson, and R. Ullmann, RFC1356. 2188 [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and 2189 A. Malis, RFC1490. 2191 [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, 2192 Yakov Rekhter, Dilip Kandlur, RFC1937. 2194 [11] Support for Multicast over UNI 3.0/3.1 based ATM Networks, 2195 G. Armitage, Work In Progress. 2197 [12] Server Cache Synchronization Protocol (SCSP) - NBMA, 2198 J. Luciani, G. Armitage, J. Halpern, Work In Progress. 2200 [13] NHRP for Destinations off the NBMA Subnetwork, 2201 Y. Rekhter, Work In Progress. 2203 [14] Classical IP to NHRP Transition, J. Luciani, et al., Work In Progress. 2205 Acknowledgments 2207 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 2208 Govidan of ISI for their work on NBMA ARP and the original NHRP 2209 draft, which served as the basis for this work. Russell Gardo of 2210 IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern 2211 of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of 2212 cisco, and Grenville Armitage of Bellcore should also be acknowledged 2213 for comments and suggestions that improved this work substantially. 2214 We would also like to thank the members of the ION working group of 2215 the IETF, whose review and discussion of this document have been 2216 invaluable. 2218 Authors' Addresses 2219 James V. Luciani Dave Katz 2220 Bay Networks cisco Systems 2221 3 Federal Street 170 W. Tasman Dr. 2222 Mail Stop: BL3-04 San Jose, CA 95134 USA 2223 Billerica, MA 01821 Phone: +1 408 526 8284 2224 Phone: +1 508 439 4734 Email: dkatz@cisco.com 2225 Email: luciani@baynetworks.com 2227 David Piscitello Bruce Cole 2228 Core Competence cisco Systems 2229 1620 Tuckerstown Road 170 W. Tasman Dr. 2230 Dresher, PA 19025 USA San Jose, CA 95134 USA 2231 Phone: +1 215 830 0692 Phone: +1 408 526 4000 2232 Email: dave@corecom.com Email: bcole@cisco.com