idnits 2.17.1 draft-ietf-rolc-nhrp-09.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-03-28) 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 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 255: '...quest for a given destination MUST NOT...' RFC 2119 keyword, line 283: '... NHSs MUST NOT respond to authoritat...' RFC 2119 keyword, line 427: '... an NHC, the NHS MUST send NHRP messag...' RFC 2119 keyword, line 428: '...C. That is, the NHRP message MUST NOT...' RFC 2119 keyword, line 432: '...ch serves an NHC SHOULD have a direct ...' (96 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 903 has weird spacing: '... wishes to r...' == Line 1813 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 (January 1997) is 9934 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0xAA-AA-03' on line 523 -- Looks like a reference, but probably isn't: '0x00-00-5E' on line 523 -- Looks like a reference, but probably isn't: '0x00-03' on line 523 == Unused Reference: '2' is defined on line 2089, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2096, 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') Summary: 18 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing over Large Clouds Working Group James V. Luciani 3 INTERNET-DRAFT (Bay Networks) 4 Dave Katz 5 (cisco Systems) 6 David Piscitello 7 (Core Competence, Inc.) 8 Bruce Cole 9 (cisco Systems) 10 Expires January 1997 12 NBMA Next Hop Resolution Protocol (NHRP) 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 30 Rim). 32 Abstract 34 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 35 NHRP can be used by a source station (host or router) connected to a 36 Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the 37 internetworking layer address and NBMA subnetwork addresses of the 38 "NBMA next hop" towards a destination station. If the destination is 39 connected to the NBMA subnetwork, then the NBMA next hop is the 40 destination station itself. Otherwise, the NBMA next hop is the 41 egress router from the NBMA subnetwork that is "nearest" to the 42 destination station. NHRP is intended for use in a multiprotocol 43 internetworking layer environment over NBMA subnetworks. 45 This document is intended to be a functional superset of the NBMA 46 Address Resolution Protocol (NARP) documented in [1]. 48 Operation of NHRP as a means of establishing a transit path across an 49 NBMA subnetwork between two routers will be addressed in a separate 50 document. 52 1. Introduction 54 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 55 (a host or router), wishing to communicate over a Non-Broadcast, 56 Multi-Access (NBMA) subnetwork, to determine the internetworking 57 layer addresses and NBMA addresses of suitable "NBMA next hops" 58 toward a destination station. A subnetwork can be non-broadcast 59 either because it technically doesn't support broadcasting (e.g., an 60 X.25 subnetwork) or because broadcasting is not feasible for one 61 reason or another (e.g., an SMDS multicast group or an extended 62 Ethernet would be too large). If the destination is connected to the 63 NBMA subnetwork, then the NBMA next hop is the destination station 64 itself. Otherwise, the NBMA next hop is the egress router from the 65 NBMA subnetwork that is "nearest" to the destination station. 67 One way to model an NBMA network is by using the notion of logically 68 independent IP subnets (LISs). LISs, as defined in [3] and [4], have 69 the following properties: 71 1) All members of a LIS have the same IP network/subnet number 72 and address mask. 74 2) All members of a LIS are directly connected to the same 75 NBMA subnetwork. 77 3) All hosts and routers outside of the LIS are accessed via a router. 79 4) All members of a LIS access each other directly (without routers). 81 Address resolution as described in [3] and [4] only resolves the next 82 hop address if the destination station is a member of the same LIS as 83 the source station; otherwise, the source station must forward 84 packets to a router that is a member of multiple LIS's. In multi-LIS 85 configurations, hop-by-hop address resolution may not be sufficient 86 to resolve the "NBMA next hop" toward the destination station, and IP 87 packets may have multiple IP hops through the NBMA subnetwork. 89 Another way to model NBMA is by using the notion of Local Address 90 Groups (LAGs) [10]. The essential difference between the LIS and the 91 LAG models is that while with the LIS model the outcome of the 92 "local/remote" forwarding decision is driven purely by addressing 93 information, with the LAG model the outcome of this decision is 94 decoupled from the addressing information and is coupled with the 95 Quality of Service and/or traffic characteristics. With the LAG 96 model any two entities on a common NBMA network could establish a 97 direct communication with each other, irrespective of the entities' 98 addresses. 100 Support for the LAG model assumes the existence of a mechanism that 101 allows any entity (i.e., host or router) connected to an NBMA network 102 to resolve an internetworking layer address to an NBMA address for 103 any other entity connected to the same NBMA network. This resolution 104 would take place regardless of the address assignments to these 105 entities. NHRP describes such a mechanism. For example, when the 106 internetworking layer address is of type IP, once the NBMA next hop 107 has been resolved, the source may either start sending IP packets to 108 the destination (in a connectionless NBMA subnetwork such as SMDS) or 109 may first establish a connection to the destination with the desired 110 bandwidth (in a connection-oriented NBMA subnetwork such as ATM). 112 Use of NHRP may be sufficient for hosts doing address resolution when 113 those hosts are directly connected to an NBMA subnetwork, allowing 114 for straightforward implementations in NBMA stations. NHRP also has 115 the capability of determining the egress point from an NBMA 116 subnetwork when the destination is not directly connected to the NBMA 117 subnetwork and the identity of the egress router is not learned by 118 other methods (such as routing protocols). Optional extensions to 119 NHRP provide additional robustness and diagnosability. 121 Address resolution techniques such as those described in [3] and [4] 122 may be in use when NHRP is deployed. ARP servers and services over 123 NBMA subnetworks may be required to support hosts that are not 124 capable of dealing with any model for communication other than the 125 LIS model, and deployed hosts may not implement NHRP but may continue 126 to support ARP variants such as those described in [3] and [4]. NHRP 127 is intended to reduce or eliminate the extra router hops required by 128 the LIS model, and can be deployed in a non-interfering manner 129 alongside existing ARP services. 131 The operation of NHRP to establish transit paths across NBMA 132 subnetworks between two routers requires additional mechanisms to 133 avoid stable routing loops, and will be described in a separate 134 document. 136 2. Overview 138 2.1 Terminology 140 The term "network" is highly overloaded, and is especially confusing 141 in the context of NHRP. We use the following terms: 143 Internetwork layer--the media-independent layer (IP in the case of 144 TCP/IP networks). 146 Subnetwork layer--the media-dependent layer underlying the 147 internetwork layer, including the NBMA technology (ATM, X.25, SMDS, 148 etc.) 150 The term "server", unless explicitly stated to the contrary, refers 151 to an Next Hop Server (NHS). An NHS is an entity performing the 152 Next Hop Resolution Protocol service within the NBMA cloud. An NHS 153 is always tightly coupled with a routing entity (router, route 154 server or edge device) although the converse is not yet guaranteed 155 until ubiquitous deployment of this functionality occurs. 157 The term "client", unless explicitly stated to the contrary, refers 158 to an Next Hop Resolution Protocol client (NHC). An NHC is an 159 entity which initiates NHRP requests of various types in order to 160 obtain access to the NHRP service. 162 The term "station" generally refers to a host or router which 163 contains an NHRP entity. Occasionally, the term station will 164 describe a "user" of the NHRP client or service functionality; the 165 difference in usage is largely semantic. 167 2.2 Protocol Overview 169 In this section, we briefly describe how a source S (which 170 potentially can be either a router or a host) uses NHRP to determine 171 the "NBMA next hop" to destination D. 173 For administrative and policy reasons, a physical NBMA subnetwork may 174 be partitioned into several, disjoint "Logical NBMA subnetworks". A 175 Logical NBMA subnetwork is defined as a collection of hosts and 176 routers that share unfiltered subnetwork connectivity over an NBMA 177 subnetwork. "Unfiltered subnetwork connectivity" refers to the 178 absence of closed user groups, address screening or similar features 179 that may be used to prevent direct communication between stations 180 connected to the same NBMA subnetwork. (Hereafter, unless otherwise 181 specified, we use the term "NBMA subnetwork" to mean *logical* NBMA 182 subnetwork.) 184 Placed within the NBMA subnetwork are one or more entities that 185 implement the NHRP protocol. Such stations which are capable of 186 answering NHRP Resolution Requests are known as "Next Hop Servers" 187 (NHSs). Each NHS serves a set of destination hosts, which may or may 188 not be directly connected to the NBMA subnetwork. NHSs cooperatively 189 resolve the NBMA next hop within their logical NBMA subnetwork. In 190 addition to NHRP, NHSs may support "classical" ARP service; however, 191 this will be the subject of a separate document. 193 An NHS maintains a cache which contains protocol layer address to 194 NBMA subnetwork layer address resolution information. This cache can 195 be constructed from information obtained from NHRP Register packets 196 (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply 197 packets, or through mechanisms outside the scope of this document 198 (examples of such mechanisms might include ARP[3] and pre-configured 199 tables). Section 6.2 further describes cache management issues. 201 For a station within a given LIS to avoid providing NHS 202 functionality, there must be one or more NHSs within the NBMA 203 subnetwork which are providing authoritative address resolution 204 information on its behalf. Such an NHS is said to be "serving" the 205 station. A stations on a LIS that lacks NHS functionality and is a 206 client of the NHRP service is known as NHRP Client or just NHCs. If 207 a serving NHS is to be able to supply the address resolution 208 information for an NHC then NHSs must exist at each hop along all 209 routed paths between the NHC making the resolution request and the 210 destination NHC. The last NHRP entity along the routed path is the 211 serving NHS; that is, NHRP Resolution Requests are not forwarded to 212 destination NHCs but rather are processed by the serving NHS. 214 An NHC also maintains a cache of protocol address to NBMA address 215 resolution information. This cache is populated through information 216 obtained from NHRP Resolution Reply packets, from manual 217 configuration, or through mechanisms outside the scope of this 218 document. 220 The protocol proceeds as follows. An event occurs triggering station 221 S to want to resolve the NBMA address of a path to D. This is most 222 likely to be when a data packet addressed to station D is to be 223 emitted from station S (either because station S is a host, or 224 station S is a transit router), but the address resolution could also 225 be triggered by other means (a routing protocol update packet, for 226 example). Station S first determines the next hop to station D 227 through normal routing processes (for a host, the next hop may simply 228 be the default router; for routers, this is the "next hop" to the 229 destination internetwork layer address). If the destination's 230 address resolution information is already available in S's cache then 231 that information is used to forward the packet. Otherwise, if the 232 next hop is reachable through one of its NBMA interfaces, S 233 constructs an NHRP Resolution Request packet (see Section 5.2.1) 234 containing station D's internetwork layer address as the (target) 235 destination address, S's own internetwork layer address as the source 236 address (Next Hop Resolution Request initiator), and station S's NBMA 237 addressing information. Station S may also indicate that it prefers 238 an authoritative NHRP Resolution Reply (i.e., station S only wishes 239 to receive an NHRP Resolution Reply from an NHS serving the 240 destination NHC). Station S emits the NHRP Resolution Request packet 241 towards the destination. 243 If the NHRP Resolution Request is triggered by a data packet then S 244 may, while awaiting an NHRP Resolution Reply, choose to dispose of 245 the data packet in one of the following ways: 247 (a) Drop the packet 248 (b) Retain the packet until the NHRP Resolution Reply arrives 249 and a more optimal path is available 250 (c) Forward the packet along the routed path toward D 252 The choice of which of the above to perform is a local policy matter, 253 though option (c) is the recommended default, since it may allow data 254 to flow to the destination while the NBMA address is being resolved. 255 Note that an NHRP Resolution Request for a given destination MUST NOT 256 be triggered on every packet. 258 When the NHS receives an NHRP Resolution Request, a check is made to 259 see if it serves station D. If the NHS does not serve D, the NHS 260 forwards the NHRP Resolution Request to another NHS. Mechanisms for 261 determining how to forward the NHRP Resolution Request are discussed 262 in Section 3. 264 If this NHS serves D, the NHS resolves station D's NBMA address 265 information, and generates a positive NHRP Resolution Reply on D's 266 behalf. NHRP Resolution Replies in this scenario are always marked 267 as "authoritative". The NHRP Resolution Reply packet contains the 268 address resolution information for station D which is to be sent back 269 to S. Note that if station D is not on the NBMA subnetwork, the next 270 hop internetwork layer address will be that of the egress router 271 through which packets for station D are forwarded. 273 A transit NHS receiving an NHRP Resolution Reply may cache the 274 address resolution information contained therein. To a subsequent 275 NHRP Resolution Request, this NHS may respond with the cached, "non- 276 authoritative" address resolution information if the NHS is permitted 277 to do so (see Sections 5.2.2 and 6.2 for more information on non- 278 authoritative versus authoritative NHRP Resolution Replies). Non- 279 authoritative NHRP Resolution Replies are distinguished from 280 authoritative NHRP Resolution Replies so that if a communication 281 attempt based on non-authoritative information fails, a source 282 station can choose to send an authoritative NHRP Resolution Request. 283 NHSs MUST NOT respond to authoritative NHRP Resolution Requests with 284 cached information. 286 An NHRP Resolution Reply may be returned directly to the NHRP 287 Resolution Request initiator, without traversing the NHSs which 288 forwarded the NHRP Resolution Request, if each of the following 289 criteria are satisfied: 291 (a) Direct communication is available via datagram transfer 292 (e.g., SMDS) or the NHS has an existing virtual circuit 293 connection to the NHC which sent the NHRP Resolution Request 294 or NHS is permitted to open a connection the NHC. 295 (b) The NHRP Resolution Request initiator has not included the 296 NHRP Reverse NHS record Extension (see Section 5.3.3). 297 (c) The authentication policy in force permits direct 298 communication between the NHS and the NHRP Resolution 299 Request initiator. 301 The purpose of allowing an NHS to send a NHRP Resolution Reply 302 directly is to reduce response time. A consequence of allowing a 303 direct NHRP Resolution Reply is that NHSs that would under normal 304 circumstances be traversed by the NHRP Resolution Reply would not 305 cache next hop information contained therein. This feature may have 306 value when the serving NHS is an egress router for the destination 307 address which is off the NBMA cloud (this implies that NHC 308 functionality is coresident with the NHS). 310 If the determination is made that no NHS in the NBMA subnetwork can 311 reply to the NHRP Resolution Request for D then a negative NHRP 312 Resolution Reply (NAK) is returned. This occurs when (a) no next-hop 313 resolution information is available for station D from any NHS, or 314 (b) an NHS is unable to forward the NHRP Resolution Request (e.g., 315 connectivity is lost). 317 NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies, 318 and NHRP Error Indications follow the routed path from sender to 319 receiver in the same fashion that NHRP Resolution Requests and NHRP 320 Resolution Replies do. That is, "requests" and "indications" follow 321 the routed path from Source Protocol Address (which is the address of 322 the station initiating the communication) to the Destination Protocol 323 Address. "Replies", on the other hand, follow the routed path from 324 the Destination Protocol Address back to the Source Protocol Address 325 with the exceptions mentioned above where a direct VC may be created. 326 In the case of a NHRP Registration Reply and in the case of an NHC 327 initiated NHRP Purge Request, the packet is always returned via a 328 direct VC (see Sections 5.2.4 and 5.2.5). 330 NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA 331 subnetwork however further study is being done in this area (see 332 Section 7). Thus, the internetwork layer traffic out of and into an 333 NBMA subnetwork always traverses an internetwork layer router at its 334 border. Internetwork layer filtering can then be implemented at 335 these border routers. 337 NHRP optionally provides a mechanism to send a NHRP Resolution Reply 338 which contains aggregated address resolution information. For 339 example, suppose that router X is the next hop from station S to 340 station D and that X is an egress router for all stations sharing an 341 internetwork layer address prefix with station D. When an NHRP 342 Resolution Reply is generated in response to a NHRP Resolution 343 Request, the responder may augment the internetwork layer address of 344 station D with a prefix length (see Section 5.2.0.1). A subsequent 345 (non-authoritative) NHRP Resolution Request for some destination that 346 shares an internetwork layer address prefix (for the number of bits 347 specified in the prefix length) with D may be satisfied with this 348 cached information. See section 6.2 regarding caching issues. 350 To dynamically detect subnetwork-layer filtering in NBMA subnetworks 351 (e.g., X.25 closed user group facility, or SMDS address screens), to 352 trace the routed path that an NHRP packet takes, or to provide loop 353 detection and diagnostic capabilities, a "Route Record" may be 354 included in NHRP packets (see Sections 5.3.2 and 5.3.3). The Route 355 Record extensions are the NHRP Forward Transit NHS Record Extension 356 and the NHRP Reverse Transit NHS Record Extension. They contain the 357 internetwork (and subnetwork layer) addresses of all intermediate 358 NHSs between source and destination and between destination and 359 source respectively. When a source station is unable to communicate 360 with the responder (e.g., an attempt to open an SVC fails), it may 361 attempt to do so successively with other subnetwork layer addresses 362 in these extensions until it succeeds (if authentication policy 363 permits such action). This approach can find a suitable egress point 364 in the presence of subnetwork-layer filtering (which may be 365 source/destination sensitive, for instance, without necessarily 366 creating separate logical NBMA subnetworks) or subnetwork-layer 367 congestion (especially in connection-oriented media). 369 3. Deployment 371 NHRP Resolution Requests traverse one or more hops within an NBMA 372 subnetwork before reaching the station that is expected to generate a 373 response. Each station, including the source station, chooses a 374 neighboring NHS to which it will forward the NHRP Resolution Request. 375 The NHS selection procedure typically involves applying a destination 376 protocol layer address to the protocol layer routing table which 377 causes a routing decision to be returned. This routing decision is 378 then used to forward the NHRP Resolution Request to the downstream 379 NHS. The destination protocol layer address previously mentioned is 380 carried within the NHRP Resolution Request packet. Note that even 381 though a protocol layer address was used to acquire a routing 382 decision, NHRP packets are not encapsulated within a protocol layer 383 header but rather are carried at the NBMA layer using the 384 encapsulation described in Section 5. 386 Each NHS/router examines the NHRP Resolution Request packet on its 387 way toward the destination. Each NHS which the NHRP packet traverses 388 on the way to the packet's destination might modify the packet (e.g., 389 updating the Forward Record extension). Ignoring error situations, 390 the NHRP Resolution Request eventually arrives at a station that is 391 to generate an NHRP Resolution Reply. This responding station 392 "serves" the destination. The responding station generates a NHRP 393 Resolution Reply using the source protocol address from within the 394 NHRP packet to determine where the NHRP Resolution Reply should be 395 sent. 397 Rather than use routing to determine the next hop for an NHRP packet, 398 an NHS may use static configuration information (or other applicable 399 means) in order to determine to which neighboring NHSs to forward the 400 NHRP Resolution Request packet. The use of static configuration 401 information for this purpose is beyond the scope of this document. 403 The NHS serving a particular destination must lie along the routed 404 path to that destination. In practice, this means that all egress 405 routers must double as NHSs serving the destinations beyond them, and 406 that hosts on the NBMA subnetwork are served by routers that double 407 as NHSs. Also, this implies that forwarding of NHRP packets within 408 an NBMA subnetwork requires a contiguous deployment of NHRP capable 409 routers. During migration to NHRP, it cannot be expected that all 410 routers within the NBMA subnetwork are NHRP capable. Thus, NHRP 411 traffic which would otherwise need to be forwarded through such 412 routers can be expected to be dropped due to the NHRP packet not 413 being recognized. In this case, NHRP will be unable to establish any 414 transit paths whose discovery requires the traversal of the non-NHRP 415 speaking routers. If the client has tried and failed to acquire a 416 cut through path then the client should use the network layer routed 417 path as a default. 419 If an NBMA technology offers a group, an anycast, or a multicast 420 addressing feature then the NHC may be configured with such an 421 address which would be assigned to the appropriate NHSs. The NHC 422 might then submit NHRP Resolution Requests to such an address, 423 eliciting a response from one or more NHSs, depending on the response 424 strategy selected. Note that the constraints described in Section 2 425 regarding directly sending NHRP Resolution Reply may apply. 427 When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined 428 for the NHC directly to the NHC. That is, the NHRP message MUST NOT 429 transit through any NHS which is not serving the NHC when the NHRP 430 message is currently at an NHS which does serve the NHC (this, of 431 course, assumes the NHRP message is destined for the NHC). Further, 432 an NHS which serves an NHC SHOULD have a direct NBMA level connection 433 to that NHC (see Section 5.2.3 and 5.2.4 for examples). 435 With the exception of NHRP Registration Requests (see Section 5.2.3 436 and 5.2.4 for details of the NHRP Registration Request case), an NHC 437 MUST send NHRP messages over a direct NBMA level connection between 438 the serving NHS and the served NHC. 440 It may not be desirable to maintain semi-permanent NBMA level 441 connectivity between the NHC and the NHS. In this case, when NBMA 442 level connectivity is initially setup between the NHS and the NHC (as 443 described in Section 5.2.4), the NBMA address of the NHS should be 444 obtained through the NBMA level signaling technology. This address 445 should be stored for future use in setting up subsequent NBMA level 446 connections. A somewhat more information rich technique to obtain 447 the address information (and more) of the serving NHS would be for 448 the NHC to include the Responder Address extension (see Section 449 5.3.1) in the NHRP Registration Request and to store the information 450 returned to the NHC in the Responder Address extension which is 451 subsequently included in the NHRP Registration Reply. Note also 452 that, in practice, a client's default router should also be its NHS; 453 thus a client may be able to know the NBMA address of its NHS from 454 the configuration which was already required for the client to be 455 able to communicate. Further, as mentioned in Section 4, NHCs may be 456 configured with the addressing information of one or more NHSs. 458 4. Configuration 460 Next Hop Clients 462 An NHC connected to an NBMA subnetwork MAY be configured with the 463 Protocol address(es) and NBMA address(es) of its NHS(s). The 464 NHS(s) will likely also represent the NHC's default or peer 465 routers, so their NBMA addresses may be obtained from the NHC's 466 existing configuration. If the NHC is attached to several 467 subnetworks (including logical NBMA subnetworks), the NHC should 468 also be configured to receive routing information from its NHS(s) 469 and peer routers so that it can determine which internetwork layer 470 networks are reachable through which subnetworks. 472 Next Hop Servers 474 An NHS is configured with knowledge of its own internetwork layer 475 and NBMA addresses. An NHS MAY also be configured with a set of 476 internetwork layer address prefixes that correspond to the 477 internetwork layer addresses of the stations it serves. The NBMA 478 addresses of the stations served by the NHS may be learned via NHRP 479 Registration packets. 481 If a served NHC is attached to several subnetworks, the 482 router/route-server coresident with the serving NHS may also need 483 to be configured to advertise routing information to such NHCs. 485 If an NHS acts as an egress router for stations connected to other 486 subnetworks than the NBMA subnetwork, the NHS must, in addition to 487 the above, be configured to exchange routing information between 488 the NBMA subnetwork and these other subnetworks. 490 In all cases, routing information is exchanged using conventional 491 intra-domain and/or inter-domain routing protocols. 493 5. NHRP Packet Formats 494 This section describes the format of NHRP packets. In the following, 495 unless otherwise stated explicitly, the unqualified term "request" 496 refers generically to any of the NHRP packet types which are 497 "requests". Further, unless otherwise stated explicitly, the 498 unqualified term "reply" refers generically to any of the NHRP packet 499 types which are "replies". 501 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 502 Extensions Part. The Fixed Part is common to all NHRP packet types. 503 The Mandatory Part MUST be present, but varies depending on packet 504 type. The Extensions Part also varies depending on packet type, and 505 need not be present. 507 The length of the Fixed Part is fixed at 20 octets. The length of 508 the Mandatory Part is determined by the contents of the extensions 509 offset field (ar$extoff). If ar$extoff=0x0 then the mandatory part 510 length is equal to total packet length (ar$pktsz) minus 20 otherwise 511 the mandatory part length is equal to ar$extoff minus 20. The length 512 of the Extensions Part is implied by ar$pktsz minus ar$extoff. NHSs 513 may increase the size of an NHRP packet as a result of extension 514 processing, but not beyond the offered maximum SDU size of the NBMA 515 network. 517 NHRP packets are encapsulated using the native formats used on the 518 particular NBMA network over which NHRP is carried. For example, 519 SMDS networks always use LLC/SNAP encapsulation at the NBMA layer, 520 and an NHRP packet is preceded by the following LLC/SNAP 521 encapsulation: 523 [0xAA-AA-03] [0x00-00-5E] [0x00-03] 525 The first three octets are LLC, indicating that SNAP follows. The 526 SNAP OUI portion is the IANA's OUI, and the SNAP PID portion 527 identifies NHRP (see [4]). 529 ATM uses either LLC/SNAP encapsulation of each packet (including 530 NHRP), or uses no encapsulation on VCs dedicated to a single protocol 531 (see [7]). Frame Relay and X.25 both use NLPID/SNAP encapsulation or 532 identification of NHRP, using a NLPID of 0x0080 and the same SNAP 533 contents as above (see [8], [9]). 535 Fields marked "unused" MUST be set to zero on transmission, and 536 ignored on receipt. 538 Most packet types (ar$op.type) have both internetwork layer 539 protocol-independent fields and protocol-specific fields. The 540 protocol type/snap fields (ar$pro.type/snap) qualify the format of 541 the protocol-specific fields. 543 5.1 NHRP Fixed Header 545 The Fixed Part of the NHRP packet contains those elements of the NHRP 546 packet which are always present and do not vary in size with the type 547 of packet. 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | ar$afn | ar$pro.type | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | ar$pro.snap | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | ar$pro.snap | ar$hopcnt | ar$pktsz | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | ar$chksum | ar$extoff | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | ar$op.version | ar$op.type | ar$shtl | ar$sstl | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 ar$afn 564 Defines the type of "link layer" addresses being carried. This 565 number is taken from the 'address family number' list specified in 566 [6]. This field has implications to the coding of ar$shtl and 567 ar$sstl as described below. 569 ar$pro.type 570 field is a 16 bit unsigned integer representing the following 571 number space: 573 0x0000 to 0x00FF Protocols defined by the equivalent NLPIDs. 574 0x0100 to 0x03FF Reserved for future use by the IETF. 575 0x0400 to 0x04FF Allocated for use by the ATM Forum. 576 0x0500 to 0x05FF Experimental/Local use. 577 0x0600 to 0xFFFF Protocols defined by the equivalent Ethertypes. 579 (based on the observations that valid Ethertypes are never smaller 580 than 0x600, and NLPIDs never larger than 0xFF.) 582 ar$pro.snap 583 When ar$pro.type has a value of 0x0080, a SNAP encoded extension is 584 being used to encode the protocol type. This snap extension is 585 placed in the ar$pro.snap field. This is termed the 'long form' 586 protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be 587 zero on transmit and ignored on receive. The ar$pro.type field 588 itself identifies the protocol being referred to. This is termed 589 the 'short form' protocol ID. 591 In all cases, where a protocol has an assigned number in the 592 ar$pro.type space (excluding 0x0080) the short form MUST be used 593 when transmitting NHRP messages. Additionally, where a protocol has 594 valid short and long forms of identification, receivers MAY choose 595 to recognize the long form. 597 ar$hopcnt 598 The Hop count indicates the maximum number of NHSs that an NHRP 599 packet is allowed to traverse before being discarded. 601 ar$pktsz 602 The total length of the NHRP packet, in octets (excluding link 603 layer encapsulation). 605 ar$chksum 606 The standard IP checksum over the entire NHRP packet (starting with 607 the fixed header). If only the hop count field is changed, the 608 checksum is adjusted without full recomputation. The checksum is 609 completely recomputed when other header fields are changed. 611 ar$extoff 612 This field identifies the existence and location of NHRP 613 extensions. If this field is 0 then no extensions exist otherwise 614 this field represents the offset from the beginning of the NHRP 615 packet (i.e., starting from the ar$afn field) of the first 616 extension. 618 ar$op.version 619 This field is set to 0x01 for NHRP version 1. 621 ar$op.type 622 This is the NHRP packet type: NHRP Resolution Request(1), NHRP 623 Resolution Reply(2), NHRP Registration Request(3), NHRP 624 Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6), 625 or NHRP Error Indication(7). Use of NHRP packet Types in the range 626 128 to 255 are reserved for research or use in other protocol 627 development and will be administered by IANA. 629 ar$shtl 630 Type & length of source NBMA address interpreted in the context of 631 the 'address family number'[6] indicated by ar$afn (e.g., 632 ar$afn=0x0003 for NSAP, ar$afn=8 for E.164). When ar$afn=0x000F 633 (E.164 address plus NSAP subaddress) then both ar$shtl and ar$sstl 634 must be coded appropriately (see below). 636 ar$sstl 637 Type & length of source NBMA subaddress interpreted in the context 638 of the 'address family number'[6] indicated by ar$afn (e.g., 639 ar$afn=0x000F for NSAP). When an NBMA technology has no concept of 640 a subaddress, the subaddress length is always coded ar$sstl = 0 and 641 no storage is allocated for the subaddress in the appropriate 642 mandatory part. 644 ar$shtl, ar$sstl, subnetwork layer addresses, and subnetwork layer 645 subaddresses fields are coded as follows: 647 7 6 5 4 3 2 1 0 648 +-+-+-+-+-+-+-+-+ 649 |0|x| length | 650 +-+-+-+-+-+-+-+-+ 652 The most significant bit is reserved and MUST be set to zero. The 653 second most significant bit (x) is a flag indicating whether the 654 address being referred to is in: 656 - NSAP format (x = 0). 657 - Native E.164 format (x = 1). 659 For NBMA technologies that use neither NSAP nor E.164 format 660 addresses, x = 0 SHALL be used to indicate the native form for the 661 particular NBMA technology. 663 In the case where the NBMA is ATM, if a subaddress is to be included 664 then ar$afn MUST be set to 0x000F which means that if a subaddress 665 exists then it is of type NSAP. 667 The bottom 6 bits is an unsigned integer value indicating the length 668 of the associated NBMA address in octets. If this value is zero the 669 flag x is ignored. 671 5.2.0 Mandatory Part 673 The Mandatory Part of the NHRP packet contains the operation specific 674 information (e.g., NHRP Resolution Request/Reply, etc.) and variable 675 length data which is pertinent to the packet type. 677 5.2.0.1 Mandatory Part Format 679 Sections 5.2.1 through 5.2.6 have a very similar mandatory part. 680 This mandatory part includes a common header and zero or more Client 681 Information Entries (CIEs). Section 5.2.7 has a different format 682 which is specified in that section. 684 The common header looks like the following: 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Src Proto Len | Dst Proto Len | Flags | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Request ID | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Source NBMA Address (variable length) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Source NBMA Subaddress (variable length) | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Source Protocol Address (variable length) | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Destination Protocol Address (variable length) | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 And the CIEs have the following format: 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Code | Prefix Length | unused | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Maximum Transmission Unit | Holding Time | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Client NBMA Address (variable length) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Client NBMA Subaddress (variable length) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Client Protocol Address (variable length) | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 ..................... 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Code | Prefix Length | unused | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Maximum Transmission Unit | Holding Time | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Cli Addr T/L | Cli SAddr T/L | Cli Proto Len | Preference | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Client NBMA Address (variable length) | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Client NBMA Subaddress (variable length) | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Client Protocol Address (variable length) | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 The meanings of the fields are as follows: 736 Src Proto Len 737 This field holds the length in octets of the Source Protocol 738 Address. 740 Dst Proto Len 741 This field holds the length in octets of the Destination Protocol 742 Address. 744 Flags 745 These flags are specific to the given message type and they are 746 explained in each section. 748 Request ID 749 A value which, when coupled with the address of the source, 750 provides a unique identifier for the information contained in a 751 "request" packet. This value is copied directly from an "request" 752 packet into the associated "reply". When a sender of a "request" 753 receives "reply", it will compare the Request ID and source address 754 information in the received "reply" against that found in its 755 outstanding "request" list. When a match is found then the 756 "request" is considered to be acknowledged. 758 The value is taken from a 32 bit counter that is incremented each 759 time a new "request" is transmitted. The same value MUST be used 760 when resending a "request", i.e., when a "reply" has not been 761 received for a "request" and a retry is sent after an appropriate 762 interval. 764 The NBMA address/subaddress form specified below allows combined 765 E.164/NSAPA form of NBMA addressing. For NBMA technologies without a 766 subaddress concept, the subaddress field is always ZERO length and 767 ar$sstl = 0. 769 Source NBMA Address 770 The Source NBMA address field is the address of the source station 771 which is sending the "request". If the field's length as specified 772 in ar$shtl is 0 then no storage is allocated for this address at 773 all. 775 Source NBMA SubAddress 776 The Source NBMA subaddress field is the address of the source 777 station which is sending the "request". If the field's length as 778 specified in ar$sstl is 0 then no storage is allocated for this 779 address at all. 781 Source Protocol Address 782 This is the protocol address of the station which is sending the 783 "request". This is also the protocol address of the station toward 784 which a "reply" packet is sent. 786 Destination Protocol Address 787 This is the protocol address of the station toward which a 788 "request" packet is sent. 790 Code 791 This field is message specific. See the relevant message sections 792 below. In general, this field is a NAK code; i.e., when the field 793 is 0 in a reply then the packet is acknowledging a request and if 794 it contains any other value the packet contains a negative 795 acknowledgment. 797 Prefix Length 798 This field is message specific. See the relevant message sections 799 below. In general, however, this fields is used to indicate that 800 the information carried in an NHRP message pertains to an 801 equivalence class of internetwork layer addresses rather than just 802 a single internetwork layer address specified. All internetwork 803 layer addresses that match the first "Prefix Length" bit positions 804 for the specific internetwork layer address are included in the 805 equivalence class. If this field is set to 0x00 then this field 806 MUST be ignored and no equivalence information is assumed (note 807 that 0x00 is thus equivalent to 0xFF). 809 Maximum Transmission Unit 810 This field gives the maximum transmission unit for the relevant 811 client station. If this value is 0 then either the default MTU is 812 used or the MTU negotiated via signaling is used if such 813 negotiation is possible for the given NBMA. 815 Holding Time 816 The Holding Time field specifies the number of seconds for which 817 the Next Hop NBMA information specified in the CIE is considered to 818 be valid. Cached information SHALL be discarded when the holding 819 time expires. This field must be set to 0 on a NAK. 821 Cli Addr T/L 822 Type & length of next hop NBMA address specified in the CIE. This 823 field is interpreted in the context of the 'address family 824 number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM). 826 Cli SAddr T/L 827 Type & length of next hop NBMA subaddress specified in the CIE. 828 This field is interpreted in the context of the 'address family 829 number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes 830 the address an E.164 and the subaddress an ATM Forum NSAP address). 831 When an NBMA technology has no concept of a subaddress, the 832 subaddress is always null with a length of 0. When the address 833 length is specified as 0 no storage is allocated for the address. 835 Cli Proto Len 836 This field holds the length in octets of the Client Protocol 837 Address specified in the CIE. 839 Preference 840 This field specifies the preference for use of the specific CIE 841 relative to other CIEs. Higher values indicate higher preference. 842 Action taken when multiple CIEs have equal or highest preference 843 value is a local matter. 845 Client NBMA Address 846 This is the client's NBMA address. 848 Client NBMA SubAddress 849 This is the client's NBMA subaddress. 851 Client Protocol Address 852 This is the client's internetworking layer address specified. 854 Note that an NHS SHOULD NOT cache source information which is in an 855 NHRP message because this information could be inappropriately used 856 to set up a cut-through without doing proper filtering along a routed 857 path. Further, in the case where a distributed router exists in the 858 network, incorrect or incomplete information may be included in the 859 source information. 861 5.2.1 NHRP Resolution Request 863 The NHRP Resolution Request packet has a Type code of 1. Its 864 mandatory part is coded as described in Section 5.2.0.1 and the 865 message specific meanings of the fields are as follows: 867 Flags - The flags field is coded as follows: 869 0 1 870 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 |Q|A|B|U| unused | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Q 876 Set if the station sending the NHRP Resolution Request is a 877 router; clear if the it is a host. 879 A 880 This bit is set in a NHRP Resolution Request if only 881 authoritative next hop information is desired and is clear 882 otherwise. See the NHRP Resolution Reply section below for 883 further details on the "A" bit and its usage. 885 B 886 Unused (clear on transmit) 888 U 889 This is the Uniqueness bit. This bit aids in duplicate address 890 detection. When this bit is set in an NHRP Resolution Request 891 and one or more entries exist in the NHS cache which meet the 892 requirements of the NHRP Resolution Request then only the CIE in 893 the NHS's cache with this bit set will be returned. Note that 894 even if this bit was set at registration time, there may still be 895 multiple CIEs that might fulfill the NHRP Resolution Request 896 because an entire subnet can be registered through use of the 897 Prefix Length in the CIE and the address of interest might be 898 within such a subnet. If the "uniqueness" bit is set and the 899 responding NHS has one or more cache entries which match the 900 request but no such cache entry has the "uniqueness" bit set, 901 then the NHRP Resolution Reply returns with a NAK code of "13 - 902 Binding Exists But Is Not Unique" and no CIE is included. If a 903 client wishes to receive non- unique Next Hop Entries, then 904 the client must have the "uniqueness" bit set to zero in its NHRP 905 Resolution Request. Note that when this bit is set in an NHRP 906 Registration Request, only a single CIE may be specified in the 907 NHRP Registration Request and that CIE must have the Prefix 908 Length field set to 0xFF. 910 Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP 911 Resolution Request. If one is specified then that entry carries the 912 pertinent information for the client sourcing the NHRP Resolution 913 Request. Usage of the CIE in the NHRP Resolution Request is 914 described below: 916 Prefix Length 917 If a CIE is specified in the NHRP Resolution Request then the 918 Prefix Length field may be used to qualify the widest acceptable 919 prefix which may be used to satisfy the NHRP Resolution Request. 920 In the case of NHRP Resolution Request/Reply, the Prefix Length 921 specifies the equivalence class of addresses which match the 922 first "Prefix Length" bit positions of the Destination Protocol 923 Address. If the "U" bit is set in the common header then this 924 field MUST be set to 0xFF. 926 Maximum Transmission Unit 927 This field gives the maximum transmission unit for the source 928 station. A possible use of this field in the NHRP Resolution 929 Request packet is for the NHRP Resolution Requester to ask for a 930 target MTU. In lieu of that usage, the CIE must be omitted. 932 All other fields in the CIE MUST be ignored and SHOULD be set to 0. 934 The Destination Protocol Address in the common header of the 935 Mandatory Part of this message contains the protocol address of the 936 station for which resolution is desired. An NHC MUST send the NHRP 937 Resolution Request directly to one of its serving NHSs (see Section 3 938 for more information). 940 5.2.2 NHRP Resolution Reply 942 The NHRP Resolution Reply packet has a Type code of 2. CIEs 943 correspond to Next Hop Entries in an NHS's cache which match the 944 criteria in the NHRP Resolution Request. Its mandatory part is coded 945 as described in Section 5.2.0.1. The message specific meanings of 946 the fields are as follows: 948 Flags - The flags field is coded as follows: 950 0 1 951 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |Q|A|B|U| unused | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Q 957 Copied from the NHRP Resolution Request. Set if the NHRP 958 Resolution Requester is a router; clear if it is a host. 960 A 961 Set if the next hop CIE in the NHRP Resolution Reply is 962 authoritative; clear if the NHRP Resolution Reply is non- 963 authoritative. 965 When an NHS receives a NHRP Resolution Request for authoritative 966 information for which it is the authoritative source, it MUST 967 respond with a NHRP Resolution Reply containing all and only 968 those next hop CIEs which are contained in the NHS's cache which 969 both match the criteria of the NHRP Resolution Request and are 970 authoritative cache entries. An NHS is an authoritative source 971 for a NHRP Resolution Request if the information in the NHS's 972 cache matches the NHRP Resolution Request criteria and that 973 information was obtained through a NHRP Registration Request or 974 through synchronization with an NHS which obtained this 975 information through a NHRP Registration Request. An 976 authoritative cache entry is one which is obtained through a NHRP 977 Registration Request or through synchronization with an NHS which 978 obtained this information through a NHRP Registration Request. 980 An NHS obtains non-authoriative CIEs through promiscuous 981 listening to NHRP packets other than NHRP Registrations which are 982 directed at it. A NHRP Resolution Request which indicates a 983 request for non-authoritative information should cause a NHRP 984 Resolution Reply which contains all entries in the replying NHS's 985 cache (i.e., both authoritative and non-authoritative) which 986 match the criteria specified in the request. 988 B 989 Set if the association between the destination and the next hop 990 information is guaranteed to be stable for the lifetime of the 991 information (the holding time). This is the case if the Next Hop 992 protocol address identifies the destination (though it may be 993 different in value than the Destination address if the 994 destination system has multiple addresses) or if the destination 995 is not connected directly to the NBMA subnetwork but the egress 996 router to that destination is guaranteed to be stable (such as 997 when the destination is immediately adjacent to the egress router 998 through a non-NBMA interface). This information affects caching 999 strategies (see section 6.2). 1001 U 1002 This is the Uniqueness bit. See the NHRP Resolution Request 1003 section above for details. When this bit is set only, only one 1004 CIE is included since only one unique binding should exist in an 1005 NHS's cache. 1007 One or more CIEs are specified in the NHRP Resolution Reply. Each CIE 1008 contains NHRP next hop information which the responding NHS has 1009 cached and which matches the parameters specified in the NHRP 1010 Resolution Request. If no match is found by the NHS issuing the NHRP 1011 Resolution Reply then a single CIE is enclosed with the a CIE Code 1012 set appropriately (see below) and all other fields MUST be ignored 1013 and SHOULD be set to 0. In order to facilitate the use of NHRP by 1014 minimal client implementations, the first CIE MUST contain the next 1015 hop with the highest preference value so that such an implementation 1016 need parse only a single CIE. 1018 Code 1019 If this field is set to zero then this packet contains a 1020 positively acknowledged NHRP Resolution Reply. If this field 1021 contains any other value then this message contains an NHRP 1022 Resolution Reply NAK which means that an appropriate 1023 internetworking layer to NBMA address binding was not available 1024 in the responding NHS's cache. If NHRP Resolution Reply contains 1025 a Client Information Entry with a NAK Code other than 0 then it 1026 MUST NOT contain any other CIE. Currently defined NAK Codes are 1027 as follows: 1029 12 - No Internetworking Layer Address to NBMA Address Binding 1030 Exists 1032 This code states that there were absolutely no internetworking 1033 layer address to NBMA address bindings found in the responding 1034 NHS's cache. 1036 13 - Binding Exists But Is Not Unique 1038 This code states that there were one or more internetworking 1039 layer address to NBMA address bindings found in the responding 1040 NHS's cache, however none of them had the uniqueness bit set. 1042 Prefix Length 1043 In the case of NHRP Resolution Reply, the Prefix Length specifies 1044 the equivalence class of addresses which match the first "Prefix 1045 Length" bit positions of the Destination Protocol Address. 1047 Holding Time 1048 The Holding Time specified in a CIE of an NHRP Resolution Reply 1049 is the amount of time remaining before the expiration of the 1050 client information which is cached at the replying NHS. It is 1051 not the value which was registered by the client. 1053 The remainder of the fields for the CIE for each next hop are 1054 filled out as they were defined when the next hop was registered 1055 with the responding NHS (or one of the responding NHS's 1056 synchronized servers) via the NHRP Registration Request. 1058 Load-splitting may be performed when more than one Client Information 1059 Entry is returned to a requester when equal preference values are 1060 specified. Also, the alternative addresses may be used in case of 1061 connectivity failure in the NBMA subnetwork (such as a failed call 1062 attempt in connection-oriented NBMA subnetworks). 1064 Any extensions present in the NHRP Resolution Request packet MUST be 1065 present in the NHRP Resolution Reply even if the extension is non- 1066 Compulsory. 1068 If an unsolicited NHRP Resolution Reply packet is received, an Error 1069 Indication of type Invalid NHRP Resolution Reply Received SHOULD be 1070 sent in response. 1072 When an NHS that serves a given NHC receives an NHRP Resolution Reply 1073 destined for that NHC then the NHS must MUST send the NHRP Resolution 1074 Reply directly to the NHC (see Section 3). 1076 5.2.3 NHRP Registration Request 1078 The NHRP Registration Request is sent from a station to an NHS to 1079 notify the NHS of the station's NBMA information. It has a Type code 1080 of 3. Each CIE corresponds to Next Hop information which is to be 1081 cached at an NHS. The mandatory part of an NHRP Registration Request 1082 is coded as described in Section 5.2.0.1. The message specific 1083 meanings of the fields are as follows: 1085 Flags - The flags field is coded as follows: 1087 0 1 1088 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 |U| unused | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 U 1094 This is the Uniqueness bit. When set in an NHRP Registration 1095 Request, this bit indicates that the registration of the protocol 1096 address is unique within the confines of the set of synchronized 1097 NHSs. This "uniqueness" qualifier MUST be stored in the NHS/NHC 1098 cache. Any attempt to register a binding between the protocol 1099 address and an NBMA address when this bit is set MUST be rejected 1100 with a Code of "14 - Unique Internetworking Layer Address Already 1101 Registered" if the replying NHS already has a cache entry for the 1102 protocol address and the cache entry has the "uniqueness" bit 1103 set. A registration of a CIE's information is rejected when the 1104 CIE is returned with the Code field set to anything other than 1105 0x00. See the description of the uniqueness bit in NHRP 1106 Resolution Request section above for further details. When this 1107 bit is set only, only one CIE MAY be included in the NHRP 1108 Registration Request. 1110 Request ID 1111 The request ID has the same meaning as described in Section 1112 5.2.0.1. However, the request ID for NHRP Registrations which is 1113 maintained at each client MUST be kept in non-volatile memory so 1114 that when a client crashes and reregisters there will be no 1115 inconsistency in the NHS's database. In order to reduce the 1116 overhead associated with updating non-volatile memory, the actual 1117 updating need not be done with every increment of the Request ID 1118 but could be done, for example, every 50 or 100 increments. In 1119 this scenario, when a client crashes and reregisters it knows to 1120 add 100 to the value of the Request ID in the non-volatile memory 1121 before using the Request ID for subsequent registrations. 1123 One or more CIEs are specified in the NHRP Registration Request. 1124 Each CIE contains next hop information which a client is attempting 1125 to register with its servers. Generally, all fields in CIEs enclosed 1126 in NHRP Registration Requests are coded as described in Section 1127 5.2.0.1. However, if a station is only registering itself with the 1128 NHRP Registration Request then it MAY code the Cli Addr T/L, Cli 1129 SAddr T/L, and Cli Proto Len as zero which signifies that the client 1130 address information is to be taken from the source information in the 1131 common header (see Section 5.2.0.1). Below, further clarification is 1132 given for some fields in a CIE in the context of a NHRP Registration 1133 Request. 1135 Code 1136 This field is set to 0x00 in NHRP Registration Requests. 1138 Prefix Length 1140 This field may be used in a NHRP Registration Request to register 1141 equivalence information for the Client Protocol Address specified 1142 in the CIE of an NHRP Registration Request In the case of NHRP 1143 Registration Request, the Prefix Length specifies the equivalence 1144 class of addresses which match the first "Prefix Length" bit 1145 positions of the Client Protocol Address. If the "U" bit is set 1146 in the common header then this field MUST be set to 0xFF. 1148 The NHRP Registration Request is used to register an NHC's NHRP 1149 information with its NHSs. If an NHC is configured with the protocol 1150 address of a serving NHS then the NHC may place the NHS's protocol 1151 address in the Destination Protocol Address field of the NHRP 1152 Registration Request common header otherwise the NHC must place its 1153 own protocol address in the Destination Protocol Address field. 1155 When an NHS receives an NHRP Registration Request which has the 1156 Destination Protocol Address field set to an address which belongs to 1157 a LIS/LAG for which the NHS is serving then if the Destination 1158 Protocol Address field is equal to the Source Protocol Address field 1159 (which would happen if the NHC put its protocol address in the 1160 Destination Protocol Address) or the Destination Protocol Address 1161 field is equal to the protocol address of the NHS then the NHS 1162 processes the NHRP Registration Request after doing appropriate error 1163 checking (including any applicable policy checking). 1165 When an NHS receives an NHRP Registration Request which has the 1166 Destination Protocol Address field set to an address which does not 1167 belong to a LIS/LAG for which the NHS is serving then the NHS 1168 forwards the packet down the routed path toward the appropriate 1169 LIS/LAG. 1171 When an NHS receives an NHRP Registration Request which has the 1172 Destination Protocol Address field set to an address which belongs to 1173 a LIS/LAG for which the NHS is serving then if the Destination 1174 Protocol Address field does not equal the Source Protocol Address 1175 field and the Destination Protocol Address field does not equal the 1176 protocol address of the NHS then the NHS forwards the message to the 1177 appropriate NHS within the LIS/LAG as specified by Destination 1178 Protocol Address field. 1180 It is possible that a misconfigured station will attempt to register 1181 with the wrong NHS (i.e., one that cannot serve it due to policy 1182 constraints or routing state). If this is the case, the NHS MUST 1183 reply with a NAK-ed Registration Reply of type Can't Serve This 1184 Address. 1186 If an NHS cannot serve a station due to a lack of resources, the NHS 1187 MUST reply with a NAK-ed Registration Reply of type Registration 1188 Overflow. 1190 In order to keep the registration entry from being discarded, the 1191 station MUST re-send the NHRP Registration Request packet often 1192 enough to refresh the registration, even in the face of occasional 1193 packet loss. It is recommended that the NHRP Registration Request 1194 packet be sent at an interval equal to one-third of the Holding Time 1195 specified therein. 1197 5.2.4 NHRP Registration Reply 1199 The NHRP Registration Reply is sent by an NHS to a client in response 1200 to that client's NHRP Registration Request. If the Code field of a 1201 CIE in the NHRP Registration Reply has anything other than 0 zero in 1202 it then the NHRP Registration Reply is a NAK otherwise the reply is 1203 an ACK. The NHRP Registration Reply has a Type code of 4. 1205 An NHRP Registration Reply is formed from an NHRP Registration 1206 Request by changing the type code to 4, updating the CIE Code field, 1207 and filling in the appropriate extensions if they exist. The message 1208 specific meanings of the fields are as follows: 1210 Attempts to register the information in the CIEs of an NHRP 1211 Registration Request may fail for various reasons. If this is the 1212 case then each failed attempt to register the information in a CIE of 1213 an NHRP Registration Request is logged in the associated NHRP 1214 Registration Reply by setting the CIE Code field to the appropriate 1215 error code as shown below: 1217 CIE Code 1219 0 - Successful Registration 1221 The information in the CIE was successfully registered with the 1222 NHS. 1224 4 - Can't Serve This Address 1226 An NHS may refuse an NHRP Registration Request attempt for 1227 administrative reasons (due to policy constraints or routing 1228 state). If so, the NHS MUST send an NHRP Registration Reply 1229 which contains a NAK code of 4. 1231 5 - Registration Overflow 1233 If an NHS cannot serve a station due to a lack of resources, 1234 the NHS MUST reply with a NAKed NHRP Registration Reply which 1235 contains a NAK code of 5. 1237 14 - Unique Internetworking Layer Address Already Registered 1238 If a client tries to register a protocol address to NBMA 1239 address binding with the uniqueness bit on and the protocol 1240 address already exists in the NHS's cache then if that cache 1241 entry also has the uniqueness bit on then this NAK Code is 1242 returned in the CIE in the NHRP Registration Reply. 1244 Due to the possible existence of asymmetric routing, an NHRP 1245 Registration Reply may not be able to merely follow the routed path 1246 back to the source protocol address specified in the common header of 1247 the NHRP Registration Reply. As a result, there MUST exist a direct 1248 NBMA level connection between the NHC and its NHS on which to send 1249 the NHRP Registration Reply before NHRP Registration Reply may be 1250 returned to the NHC. If such a connection does not exist then the 1251 NHS must setup such a connection to the NHC by using the source NBMA 1252 information supplied in the common header of the NHRP Registration 1253 Request. 1255 5.2.5 NHRP Purge Request 1257 The NHRP Purge Request packet is sent in order to invalidate cached 1258 information in a station. The NHRP Purge Request packet has a type 1259 code of 5. The mandatory part of an NHRP Purge Request is coded as 1260 described in Section 5.2.0.1. The message specific meanings of the 1261 fields are as follows: 1263 Flags - The flags field is coded as follows: 1265 0 1 1266 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 |N| unused | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 N 1272 When set, this bit tells the receiver of the NHRP Purge Request 1273 that the requester does not expect to receive an NHRP Purge 1274 Reply. If an unsolicited NHRP Purge Reply is received by a 1275 station where that station is identified in the Source Protocol 1276 Address of the packet then that packet must be ignored. 1278 One or more CIEs are specified in the NHRP Purge Request. Each CIE 1279 contains next hop information which is to be purged from an NHS/NHC 1280 cache. Generally, all fields in CIEs enclosed in NHRP Purge Requests 1281 are coded as described in Section 5.2.0.1. Below, further 1282 clarification is given for some fields in a CIE in the context of a 1283 NHRP Purge Request. 1285 Code 1286 This field is set to 0x00 in NHRP Purge Requests. 1288 Prefix Length 1290 In the case of NHRP Purge Requests, the Prefix Length specifies 1291 the equivalence class of addresses which match the first "Prefix 1292 Length" bit positions of the Client Protocol Address specified in 1293 the CIE. All next hop information which contains a protocol 1294 address which matches an element of this equivalence class is to 1295 be purged from the receivers cache. 1297 The Maximum Transmission Unit and Preference fields of the CIE are 1298 coded as zero. The Holding Time should be coded as zero but there 1299 may be some utility in supplying a "short" holding time to be 1300 applied to the matching next hop information before that 1301 information would be purged; this usage is for further study. The 1302 Client Protocol Address field and the Cli Proto Len field MUST be 1303 filled in. The Client Protocol Address is filled in with the 1304 protocol address to be purged from the receiving station's cache 1305 while the Cli Proto Len is set the length of the purged client's 1306 protocol address. All remaining fields in the CIE MAY be set to 1307 zero although the client NBMA information (and associated length 1308 fields) MAY be specified to narrow the scope of the NHRP Purge 1309 Request if requester desires. However, the receiver of an NHRP 1310 Purge Request may choose to ignore the Client NBMA information if 1311 it is supplied. 1313 An NHRP Purge Request packet is sent from an NHS to a station to 1314 cause it to delete previously cached information. This is done when 1315 the information may be no longer valid (typically when the NHS has 1316 previously provided next hop information for a station that is not 1317 directly connected to the NBMA subnetwork, and the egress point to 1318 that station may have changed). 1320 An NHRP Purge Request packet may also be sent from an NHC to an NHS 1321 with which the NHC had previously registered. This allows for an NHC 1322 to invalidate its registration with NHRP before it would otherwise 1323 expire via the holding timer. If an NHC does not have knowledge of a 1324 protocol address of a serving NHS then the NHC must place its own 1325 protocol address in the Destination Protocol Address field and 1326 forward the packet along the routed path. Otherwise, the NHC must 1327 place the protocol address of a serving NHS in this field. 1329 Serving NHSs may need to send one or more new NHRP Purge Requests as 1330 a result of receiving a purge from one of their served NHCs since the 1331 NHS may have previously responded to NHRP Resolution Requests for 1332 that NHC's NBMA information. These purges are "new" in that they are 1333 sourced by the NHS and not the NHC; that is, for each NHC that 1334 previously sent a NHRP Resolution Request for the purged NHC NBMA 1335 information, an NHRP Purge Request is sent which contains the Source 1336 Protocol/NBMA Addresses of the NHS and the Destination Protocol 1337 Address of the NHC which previously sent an NHRP Resolution Request 1338 prior to the purge. 1340 The station sending the NHRP Purge Request MAY periodically 1341 retransmit the NHRP Purge Request until either NHRP Purge Request is 1342 acknowledged or until the holding time of the information being 1343 purged has expired. Retransmission strategies for NHRP Purge 1344 Requests are a local matter. 1346 When a station receives an NHRP Purge Request, it MUST discard any 1347 previously cached information that matches the information in the 1348 CIEs. 1350 An NHRP Purge Reply MUST be returned for the NHRP Purge Request even 1351 if the station does not have a matching cache entry assuming that the 1352 "N" bit is off in the NHRP Purge Request. 1354 If the station wishes to reestablish communication with the 1355 destination shortly after receiving an NHRP Purge Request, it should 1356 make an authoritative NHRP Resolution Request in order to avoid any 1357 stale cache entries that might be present in intermediate NHSs (See 1358 section 6.2.2.). It is recommended that authoritative NHRP 1359 Resolution Requests be made for the duration of the holding time of 1360 the old information. 1362 5.2.6 NHRP Purge Reply 1364 The NHRP Purge Reply packet is sent in order to assure the sender of 1365 an NHRP Purge Request that all cached information of the specified 1366 type has been purged from the station sending the reply. The NHRP 1367 Purge Reply has a type code of 6. 1369 An NHRP Purge Reply is formed from an NHRP Purge Request by merely 1370 changing the type code in the request to 6. The packet is then 1371 returned to the requester after filling in the appropriate extensions 1372 if they exist. 1374 5.2.7 NHRP Error Indication 1376 The NHRP Error Indication is used to convey error indications to the 1377 sender of an NHRP packet. It has a type code of 7. The Mandatory 1378 Part has the following format: 1380 0 1 2 3 1381 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 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 | Src Proto Len | Dst Proto Len | unused | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Error Code | Error Offset | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Source NBMA Address (variable length) | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | Source NBMA Subaddress (variable length) | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Source Protocol Address (variable length) | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Destination Protocol Address (variable length) | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | Contents of NHRP Packet in error (variable length) | 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 Src Proto Len 1399 This field holds the length in octets of the Source Protocol 1400 Address. 1402 Dst Proto Len 1403 This field holds the length in octets of the Destination Protocol 1404 Address. 1406 Error Code 1407 An error code indicating the type of error detected, chosen from 1408 the following list: 1410 1 - Unrecognized Extension 1412 When the Compulsory bit of an extension in NHRP packet is set, 1413 the NHRP packet cannot be processed unless the extension has 1414 been processed. The responder MUST return an NHRP Error 1415 Indication of type Unrecognized Extension if it is incapable of 1416 processing the extension. However, if a transit NHS (one which 1417 is not going to generate a reply) detects an unrecognized 1418 extension, it SHALL ignore the extension. 1420 3 - NHRP Loop Detected 1422 A Loop Detected error is generated when it is determined that 1423 an NHRP packet is being forwarded in a loop. 1425 6 - Protocol Address Unreachable 1427 This error occurs when a packet it moving along the routed path 1428 and it reaches a point such that the protocol address of 1429 interest is not reachable. 1431 7 - Protocol Error 1433 A generic packet processing error has occurred (e.g., invalid 1434 version number, invalid protocol type, failed checksum, etc.) 1436 8 - NHRP SDU Size Exceeded 1438 If the SDU size of the NHRP packet exceeds the MTU size of the 1439 NBMA network then this error is returned. 1441 9 - Invalid Extension 1443 If an NHS finds an extension in a packet which is inappropriate 1444 for the packet type, an error is sent back to the sender with 1445 Invalid Extension as the code. 1447 10 - Invalid NHRP Resolution Reply Received 1449 If a client receives a NHRP Resolution Reply for a Next Hop 1450 Resolution Request which it believes it did not make then an 1451 error packet is sent to the station making the reply with an 1452 error code of Invalid Reply Received. 1454 11 - Authentication Failure 1456 If a received packet fails an authentication test then this 1457 error is returned. 1459 15 - Hop Count Exceeded 1461 The hop count which was specified in the Fixed Header of an 1462 NHRP message has been exceeded. 1464 Error Offset 1465 The offset in octets into the NHRP packet, starting at the NHRP 1466 Fixed Header, at which the error was detected. 1468 Source NBMA Address 1469 The Source NBMA address field is the address of the station which 1470 observed the error. 1472 Source NBMA SubAddress 1473 The Source NBMA subaddress field is the address of the station 1474 which observed the error. If the field's length as specified in 1475 ar$sstl is 0 then no storage is allocated for this address at all. 1477 Source Protocol Address 1478 This is the protocol address of the station which issued the Error 1479 packet. 1481 Destination Protocol Address 1482 This is the protocol address of the station which sent the packet 1483 which was found to be in error. 1485 An NHRP Error Indication packet SHALL NEVER be generated in response 1486 to another NHRP Error Indication packet. When an NHRP Error 1487 Indication packet is generated, the offending NHRP packet SHALL be 1488 discarded. In no case should more than one NHRP Error Indication 1489 packet be generated for a single NHRP packet. 1491 If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA 1492 and Source Protocol address fields of a transiting NHRP Error 1493 Indication packet then the NHS will quietly drop the packet and do 1494 nothing (this scenario would occur when the NHRP Error Indication 1495 packet was itself in a loop). 1497 Note that no extensions may be added to an NHRP Error Indication. 1499 5.3 Extensions Part 1501 The Extensions Part, if present, carries one or more extensions in 1502 {Type, Length, Value} triplets. 1504 Extensions have the following format: 1506 0 1 2 3 1507 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 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 |C|u| Type | Length | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Value... | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 C 1515 "Compulsory." If clear, and the NHS does not recognize the type 1516 code, the extension may safely be ignored. If set, and the NHS 1517 does not recognize the type code, the NHRP "request" is considered 1518 to be in error. (See below for details.) 1520 u 1521 Unused and must be set to zero. 1523 Type 1524 The extension type code (see below). The extension type is not 1525 qualified by the Compulsory bit, but is orthogonal to it. 1527 Length 1528 The length in octets of the value (not including the Type and 1529 Length fields; a null extension will have only an extension header 1530 and a length of zero). 1532 When extensions exist, the extensions list is terminated by the Null 1533 TLV, having Type = 0 and Length = 0. 1535 Extensions may occur in any order (see Section 5.3.4 for the 1536 exception), but any particular extension type may occur only once in 1537 an NHRP packet with the exception of the Vendor Private extension. 1538 The vendor-private extension may occur multiple times in a packet in 1539 order to allow for extensions which do not share the same vendor ID 1540 to be represented. It is RECOMMENDED that a given vendor include no 1541 more than one Vendor Private Extension. 1543 An NHS MUST NOT change the order of extensions. That is, the order 1544 of extensions placed in an NHRP packet by an NHC (or by an NHS when 1545 an NHS sources a packet) MUST be preserved as the packet moves 1546 between NHSs. Minimal NHC implementations MUST only recognize, but 1547 not necessarily parse, the Vendor Private extension and the End Of 1548 Extensions extension. Extensions are only present in a "reply" if 1549 they were present in the corresponding "request" with the exception 1550 of Vendor Private extensions. The previous statement is not intended 1551 to preclude the creation of NHS-only extensions which might be added 1552 to and removed from NHRP packets by the same NHS; such extensions 1553 MUST not be propagated to NHCs. 1555 The Compulsory bit provides for a means to add to the extension set. 1556 If the bit is set, the NHRP message cannot be properly processed by 1557 the station responding to the message (e.g., the station that would 1558 issue a NHRP Resolution Reply in response to a NHRP Resolution 1559 Request) without processing the extension. As a result, the 1560 responder MUST return an NHRP Error Indication of type Unrecognized 1561 Extension. If the Compulsory bit is clear then the extension can be 1562 safely ignored; however, if an ignored extension is in a "request" 1563 then it MUST be returned, unchanged, in the corresponding "reply" 1564 packet type. 1566 If a transit NHS (one which is not going to generate a "reply") 1567 detects an unrecognized extension, it SHALL ignore the extension. If 1568 the Compulsory bit is set, the transit NHS MUST NOT cache the 1569 information contained in the packet and MUST NOT identify itself as 1570 an egress router (in the Forward Record or Reverse Record 1571 extensions). Effectively, this means, if a transit NHS encounters an 1572 extension which it cannot process and which has the Compulsory bit 1573 set then that NHS MUST NOT participate in any way in the protocol 1574 exchange other than acting as a forwarding agent. 1576 Use of NHRP extension Types in the range 8192 to 16383 are reserved 1577 for research or use in other protocol development and will be 1578 administered by IANA. 1580 5.3.0 The End Of Extensions 1582 Compulsory = 1 1583 Type = 0 1584 Length = 0 1586 When extensions exist, the extensions list is terminated by the End 1587 Of Extensions/Null TLV. 1589 5.3.1 Responder Address Extension 1591 Compulsory = 1 1592 Type = 3 1593 Length = variable 1595 This extension is used to determine the address of the NHRP 1596 responder; i.e., the entity that generates the appropriate "reply" 1597 packet for a given "request" packet. In the case of an NHRP 1598 Resolution Request, the station responding may be different (in the 1599 case of cached replies) than the system identified in the Next Hop 1600 field of the NHRP Resolution Reply. Further, this extension may aid 1601 in detecting loops in the NHRP forwarding path. 1603 This extension uses a single CIE with the extension specific meanings 1604 of the fields set as follows: 1606 The Code and Prefix Length fields MUST be set to 0 and ignored. 1608 Maximum Transmission Unit 1609 This field gives the maximum transmission unit preferred by the 1610 responder. If this value is 0 then either the default MTU is used 1611 or the MTU negotiated via signaling is used if such negotiation is 1612 possible for the given NBMA. 1614 Holding Time 1615 The Holding Time field specifies the number of seconds for which 1616 the NBMA information of the responser is considered to be valid. 1617 Cached information SHALL be discarded when the holding time 1618 expires. 1620 "Client Address" information is actually "Responder Address" 1621 information for this extension. Thus, for example, Cli Addr T/L is 1622 the responder NBMA address type and length field. 1624 If a "requester" desires this information, the "requester" SHALL 1625 include this extension with a value of zero. Note that this implies 1626 that no storage is allocated for the Holding Time and Type/Length 1627 fields until the "Value" portion of the extension is filled out. 1629 If an NHS is generating a "reply" packet in response to a "request" 1630 containing this extension, the NHS SHALL include this extension, 1631 containing its protocol address in the "reply". If an NHS has more 1632 than one protocol address, it SHALL use the same protocol address 1633 consistently in all of the Responder Address, Forward Transit NHS 1634 Record, and Reverse Transit NHS Record extensions. The choice of 1635 which of several protocol address to include in this extension is a 1636 local matter. 1638 If an NHRP Resolution Reply packet being forwarded by an NHS contains 1639 a protocol address of that NHS in the Responder Address Extension 1640 then that NHS SHALL generate an NHRP Error Indication of type "NHRP 1641 Loop Detected" and discard the NHRP Resolution Reply. 1643 If an NHRP Resolution Reply packet is being returned by an 1644 intermediate NHS based on cached data, it SHALL place its own address 1645 in this extension (differentiating it from the address in the Next 1646 Hop field). 1648 5.3.2 NHRP Forward Transit NHS Record Extension 1650 Compulsory = 1 1651 Type = 4 1652 Length = variable 1654 The NHRP Forward Transit NHS record contains a list of transit NHSs 1655 through which a "request" has traversed. Each NHS SHALL append to 1656 the extension a Forward Transit NHS element (as specified below) 1657 containing its Protocol address The extension length field and the 1658 ar$chksum fields SHALL be adjusted appropriately. 1660 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1661 this extension. 1663 In addition, NHSs that are willing to act as egress routers for 1664 packets from the source to the destination SHALL include information 1665 about their NBMA Address. 1667 This extension uses a single CIE with the extension specific meanings 1668 of the fields set as follows: 1670 The Code and Prefix Length fields MUST be set to 0 and ignored. 1672 Maximum Transmission Unit 1673 This field gives the maximum transmission unit preferred by the 1674 transit NHS. If this value is 0 then either the default MTU is 1675 used or the MTU negotiated via signaling is used if such 1676 negotiation is possible for the given NBMA. 1678 Holding Time 1679 The Holding Time field specifies the number of seconds for which 1680 the NBMA information of the transit NHS is considered to be valid. 1681 Cached information SHALL be discarded when the holding time 1682 expires. 1684 "Client Address" information is actually "Forward Transit NHS 1685 Address" information for this extension. Thus, for example, Cli Addr 1686 T/L is the transit NHS NBMA address type and length field. 1688 If a "requester" wishes to obtain this information, it SHALL include 1689 this extension with a length of zero. Note that this implies that no 1690 storage is allocated for the Holding Time and Type/Length fields 1691 until the "Value" portion of the extension is filled out. 1693 If an NHS has more than one Protocol address, it SHALL use the same 1694 Protocol address consistently in all of the Responder Address, 1695 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1696 which of several Protocol addresses to include in this extension is a 1697 local matter. 1699 If a "request" that is being forwarded by an NHS contains the 1700 Protocol Address of that NHS in one of the Forward Transit NHS 1701 elements then the NHS SHALL generate an NHRP Error Indication of type 1702 "NHRP Loop Detected" and discard the "request". 1704 5.3.3 NHRP Reverse Transit NHS Record Extension 1706 Compulsory = 1 1707 Type = 5 1708 Length = variable 1710 The NHRP Reverse Transit NHS record contains a list of transit NHSs 1711 through which a "reply" has traversed. Each NHS SHALL append a 1712 Reverse Transit NHS element (as specified below) containing its 1713 Protocol address to this extension. The extension length field and 1714 ar$chksum SHALL be adjusted appropriately. 1716 The responding NHS, as described in Section 5.3.1, SHALL NOT update 1717 this extension. 1719 In addition, NHSs that are willing to act as egress routers for 1720 packets from the source to the destination SHALL include information 1721 about their NBMA Address. 1723 This extension uses a single CIE with the extension specific meanings 1724 of the fields set as follows: 1726 The Code and Prefix Length fields MUST be set to 0 and ignored. 1728 Maximum Transmission Unit 1729 This field gives the maximum transmission unit preferred by the 1730 transit NHS. If this value is 0 then either the default MTU is 1731 used or the MTU negotiated via signaling is used if such 1732 negotiation is possible for the given NBMA. 1734 Holding Time 1735 The Holding Time field specifies the number of seconds for which 1736 the NBMA information of the transit NHS is considered to be valid. 1737 Cached information SHALL be discarded when the holding time 1738 expires. 1740 "Client Address" information is actually "Reverse Transit NHS 1741 Address" information for this extension. Thus, for example, Cli Addr 1742 T/L is the transit NHS NBMA address type and length field. 1744 If a "requester" wishes to obtain this information, it SHALL include 1745 this extension with a length of zero. Note that this implies that no 1746 storage is allocated for the Holding Time and Type/Length fields 1747 until the "Value" portion of the extension is filled out. 1749 If an NHS has more than one Protocol address, it SHALL use the same 1750 Protocol address consistently in all of the Responder Address, 1751 Forward NHS Record, and Reverse NHS Record extensions. The choice of 1752 which of several Protocol addresses to include in this extension is a 1753 local matter. 1755 If a "reply" that is being forwarded by an NHS contains the Protocol 1756 Address of that NHS in one of the Reverse Transit NHS elements then 1757 the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop 1758 Detected" and discard the "reply". 1760 Note that this information may be cached at intermediate NHSs; if 1761 so, the cached value SHALL be used when generating a reply. 1763 5.3.4 NHRP Authentication Extension 1765 Compulsory = 1 1766 Type = 7 1767 Length = variable 1769 The NHRP Authentication Extension is carried in NHRP packets to 1770 convey authentication information between NHRP speakers. The 1771 Authentication Extension may be included in any NHRP "request" or 1772 "reply" only. 1774 Except in the case of an NHRP Registration Request/Reply 1775 Authentication is done pairwise on an NHRP hop-by-hop basis; i.e., 1776 the authentication extension is regenerated at each hop. In the case 1777 of an NHRP Registration Request/Reply, the Authentication is checked 1778 on an end-to-end basis rather than hop-by-hop. If a received packet 1779 fails the authentication test, the station SHALL generate an Error 1780 Indication of type "Authentication Failure" and discard the packet. 1781 Note that one possible authentication failure is the lack of an 1782 Authentication Extension; the presence or absence of the 1783 Authentication Extension is a local matter. 1785 0 1 2 3 1786 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 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Authentication Type | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | | 1791 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1792 | | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 The Authentication Type field identifies the authentication method in 1795 use. Currently assigned values are: 1797 1 - Cleartext Password 1798 2 - Keyed MD5 1800 All other values are reserved. 1802 The Authentication Data field contains the type-specific 1803 authentication information. 1805 In the case of Cleartext Password Authentication, the Authentication 1806 Data consists of a variable length password. 1808 In the case of Keyed MD5 Authentication, the Authentication Data 1809 contains the 16 byte MD5 digest of the entire NHRP packet, including 1810 the encapsulated protocol's header, with the authentication key 1811 appended to the end of the packet. The authentication key is not 1812 transmitted with the packet. The MD5 digest covers only the 1813 following fields of the NHRP packet: fixed part (with hop count, 1814 packet size and checksum being set to zero), mandatory part, 1815 Responder Address extension, and authentication extension. Note that 1816 when MD5 is used, there is an explicit ordering of the extensions 1817 such that: if the Responder Address extension exists then it MUST be 1818 the first extension in the packet and the Authentication Extension 1819 MUST be the second extension otherwise the Authentication Extension 1820 MUST be the first extension in the packet. 1822 Distribution of authentication keys is outside the scope of this 1823 document. 1825 5.3.5 NHRP Vendor-Private Extension 1827 Compulsory = 0 1828 Type = 8 1829 Length = variable 1831 The NHRP Vendor-Private Extension is carried in NHRP packets to 1832 convey vendor-private information or NHRP extensions between NHRP 1833 speakers. 1835 0 1 2 3 1836 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 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Vendor ID | Data.... | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 Vendor ID 1842 802 Vendor ID as assigned by the IEEE [6] 1844 Data 1845 The remaining octets after the Vendor ID in the payload are 1846 vendor-dependent data. 1848 This extension may be added to any "request" or "reply" packet and it 1849 is the only extension that may be included multiple times. If the 1850 receiver does not handle this extension, or does not match the Vendor 1851 ID in the extension then the extension may be completely ignored by 1852 the receiver. If a Vendor Private Extension is included in a 1853 "request" then is must be copied in the corresponding "reply". 1855 6. Protocol Operation 1857 In this section, we discuss certain operational considerations of 1858 NHRP. 1860 6.1 Router-to-Router Operation 1862 In practice, the initiating and responding stations may be either 1863 hosts or routers. However, there is a possibility under certain 1864 conditions that a stable routing loop may occur if NHRP is used 1865 between two routers. In particular, attempting to establish an NHRP 1866 path across a boundary where information used in route selection is 1867 lost may result in a routing loop. Such situations include the loss 1868 of BGP path vector information, the interworking of multiple routing 1869 protocols with dissimilar metrics (e.g, RIP and OSPF), etc. In such 1870 circumstances, NHRP should not be used. This situation can be 1871 avoided if there are no "back door" paths between the entry and 1872 egress router outside of the NBMA subnetwork. Protocol mechanisms to 1873 relax these restrictions are under investigation. 1875 In general it is preferable to use mechanisms, if they exist, in 1876 routing protocols to resolve the egress point when the destination 1877 lies outside of the NBMA subnetwork, since such mechanisms will be 1878 more tightly coupled to the state of the routing system and will 1879 probably be less likely to create loops. 1881 6.2 Cache Management Issues 1883 The management of NHRP caches in the source station, the NHS serving 1884 the destination, and any intermediate NHSs is dependent on a number 1885 of factors. 1887 6.2.1 Caching Requirements 1889 Source Stations 1891 Source stations MUST cache all received NHRP Resolution Replies that 1892 they are actively using. They also must cache "incomplete" entries, 1893 i.e., those for which a NHRP Resolution Request has been sent but 1894 which a NHRP Resolution Reply has not been received. This is 1895 necessary in order to preserve the Request ID for retries, and 1896 provides the state necessary to avoid triggering NHRP Resolution 1897 Requests for every data packet sent to the destination. 1899 Source stations MUST purge expired information from their caches. 1900 Source stations MUST purge the appropriate cached information upon 1901 receipt of an NHRP Purge Request packet. 1903 When a station has a co-resident client and NHS, the station may 1904 reply to NHRP Resolution Requests with information which the station 1905 cached as a result of the station making its own NHRP Resolution 1906 Requests and receiving its own NHRP Resolution Replies as long as the 1907 station follows the rules for Transit NHSs as seen below. 1909 Serving NHSs 1911 The NHS serving the destination (the one which responds 1912 authoritatively to NHRP Resolution Requests) SHOULD cache information 1913 about all NHRP Resolution Requests to which it has responded if the 1914 information in the NHRP Resolution Reply has the possibility of 1915 changing during its lifetime (so that an NHRP Purge Request packet 1916 can be sent). The NBMA information provided by the source station in 1917 the NHRP Resolution Request may be cached for the duration of its 1918 holding time. This information is considered to be stable, since it 1919 identifies a station directly attached to the NBMA subnetwork. An 1920 example of unstable information is NBMA information derived from a 1921 routing table, where that routing table information has not been 1922 guaranteed to be stable through administrative means. 1924 Transit NHSs 1926 A Transit NHS (lying along the NHRP path between the source station 1927 and the responding NHS) may cache information contained in NHRP 1928 Resolution Request packets that it forwards. A Transit NHS may cache 1929 information contained in NHRP Resolution Reply packets that it 1930 forwards only if that NHRP Resolution Reply has the Stable (B) bit 1931 set. It MUST discard any cached information whose holding time has 1932 expired. It may return cached information in response to non- 1933 authoritative NHRP Resolution Requests only. 1935 6.2.2 Dynamics of Cached Information 1937 NBMA-Connected Destinations 1939 NHRP's most basic function is that of simple NBMA address 1940 resolution of stations directly attached to the NBMA subnetwork. 1941 These mappings are typically very static, and appropriately chosen 1942 holding times will minimize problems in the event that the NBMA 1943 address of a station must be changed. Stale information will cause 1944 a loss of connectivity, which may be used to trigger an 1945 authoritative NHRP Resolution Request and bypass the old data. In 1946 the worst case, connectivity will fail until the cache entry times 1947 out. 1949 This applies equally to information marked in NHRP Resolution 1950 Replies as being "stable" (via the "B" bit). 1952 This also applies equally well to source stations that are routers 1953 as well as those which are hosts. 1955 Note that the information carried in the NHRP Resolution Request 1956 packet is always considered "stable" because it represents a 1957 station that is directly connected to the NBMA subnetwork. 1959 Destinations Off of the NBMA Subnetwork 1961 If the source of a NHRP Resolution Request is a host and the 1962 destination is not directly attached to the NBMA subnetwork, and 1963 the route to that destination is not considered to be "stable," the 1964 destination mapping may be very dynamic (except in the case of a 1965 subnetwork where each destination is only singly homed to the NBMA 1966 subnetwork). As such the cached information may very likely become 1967 stale. The consequence of stale information in this case will be a 1968 suboptimal path (unless the internetwork has partitioned or some 1969 other routing failure has occurred). 1971 6.3 Use of the Prefix Length field of a CIE 1973 A certain amount of care needs to be taken when using the Prefix 1974 Length field of a CIE, in particular with regard to the prefix length 1975 advertised (and thus the size of the equivalence class specified by 1976 it). Assuming that the routers on the NBMA subnetwork are exchanging 1977 routing information, it should not be possible for an NHS to create a 1978 black hole by advertising too large of a set of destinations, but 1979 suboptimal routing (e.g., extra internetwork layer hops through the 1980 NBMA) can result. To avoid this situation an NHS that wants to send 1981 the Prefix Length MUST obey the following rule: 1983 The NHS examines the Network Layer Reachability Information (NLRI) 1984 associated with the route that the NHS would use to forward towards 1985 the destination (as specified by the Destination internetwork layer 1986 address in the NHRP Resolution Request), and extracts from this 1987 NLRI the shortest address prefix such that: (a) the Destination 1988 internetwork layer address (from the NHRP Resolution Request) is 1989 covered by the prefix, (b) the NHS does not have any routes with 1990 NLRI that forms a subset of what is covered by the prefix. The 1991 prefix may then be used in the CIE. 1993 The Prefix Length field of the CIE should be used with restraint, in 1994 order to avoid NHRP stations choosing suboptimal transit paths when 1995 overlapping prefixes are available. This document specifies the use 1996 of the prefix length only when all the destinations covered by the 1997 prefix are "stable". That is, either: 1999 (a) All destinations covered by the prefix are on the NBMA network, or 2001 (b) All destinations covered by the prefix are directly attached to 2002 the NHRP responding station. 2004 Use of the Prefix Length field of the CIE in other circumstances is 2005 outside the scope of this document. 2007 6.4 Domino Effect 2009 One could easily imagine a situation where a router, acting as an 2010 ingress station to the NBMA subnetwork, receives a data packet, such 2011 that this packet triggers an NHRP Resolution Request. If the router 2012 forwards this data packet without waiting for an NHRP transit path to 2013 be established, then when the next router along the path receives the 2014 packet, the next router may do exactly the same - originate its own 2015 NHRP Resolution Request (as well as forward the packet). In fact 2016 such a data packet may trigger NHRP Resolution Request generation at 2017 every router along the path through an NBMA subnetwork. We refer to 2018 this phenomena as the NHRP "domino" effect. 2020 The NHRP domino effect is clearly undesirable. At best it may result 2021 in excessive NHRP traffic. At worst it may result in an excessive 2022 number of virtual circuits being established unnecessarily. 2023 Therefore, it is important to take certain measures to avoid or 2024 suppress this behavior. NHRP implementations for NHSs MUST provide a 2025 mechanism to address this problem. One possible strategy to address 2026 this problem would be to configure a router in such a way that NHRP 2027 Resolution Request generation by the router would be driven only by 2028 the traffic the router receives over its non-NBMA interfaces 2029 (interfaces that are not attached to an NBMA subnetwork). Traffic 2030 received by the router over its NBMA-attached interfaces would not 2031 trigger NHRP NHRP Resolution Requests. Such a router avoids the NHRP 2032 domino effect through administrative means. 2034 7. NHRP over Legacy BMA Networks 2036 There would appear to be no significant impediment to running NHRP 2037 over legacy broadcast subnetworks. There may be issues around 2038 running NHRP across multiple subnetworks. Running NHRP on broadcast 2039 media has some interesting possibilities; especially when setting up 2040 a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both 2041 end stations are legacy attached. This use for NHRP requires further 2042 research. 2044 8. Security Considerations 2046 As in any resolution protocol, there are a number of potential 2047 security attacks possible. Plausible examples include denial-of- 2048 service attacks, and masquerade attacks using register and purge 2049 packets. The use of authentication on all packets is recommended to 2050 avoid such attacks. 2052 The authentication schemes described in this document are intended to 2053 allow the receiver of a packet to validate the identity of the 2054 sender; they do not provide privacy or protection against replay 2055 attacks. 2057 Detailed security analysis of this protocol is for further study. 2059 9. Discussion 2061 The result of an NHRP Resolution Request depends on how routing is 2062 configured among the NHSs of an NBMA subnetwork. If the destination 2063 station is directly connected to the NBMA subnetwork and the the 2064 routed path to it lies entirely within the NBMA subnetwork, the NHRP 2065 Resolution Replies always return the NBMA address of the destination 2066 station itself rather than the NBMA address of some egress router. 2067 On the other hand, if the routed path exits the NBMA subnetwork, NHRP 2068 will be unable to resolve the NBMA address of the destination, but 2069 rather will return the address of the egress router. For 2070 destinations outside the NBMA subnetwork, egress routers and routers 2071 in the other subnetworks should exchange routing information so that 2072 the optimal egress router may be found. 2074 In addition to NHSs, an NBMA station could also be associated with 2075 one or more regular routers that could act as "connectionless 2076 servers" for the station. The station could then choose to resolve 2077 the NBMA next hop or just send the packets to one of its 2078 connectionless servers. The latter option may be desirable if 2079 communication with the destination is short-lived and/or doesn't 2080 require much network resources. The connectionless servers could, of 2081 course, be physically integrated in the NHSs by augmenting them with 2082 internetwork layer switching functionality. 2084 References 2086 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 2087 Govindan, RFC1735. 2089 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 2091 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 2093 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 2094 and D. Piscitello, RFC 1209. 2096 [5] Protocol Identification in the Network Layer, ISO/IEC TR 2097 9577:1990. 2099 [6] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 2101 [7] Multiprotocol Encapsulation over ATM Adaptation Layer 5, J. Heinanen, 2102 RFC1483. 2104 [8] Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, 2105 A. Malis, D. Robinson, and R. Ullmann, RFC1356. 2107 [9] Multiprotocol Interconnect over Frame Relay, T. Bradley, C. Brown, and 2108 A. Malis, RFC1490. 2110 [10] "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks, 2111 Yakov Rekhter, Dilip Kandlur, RFC1937. 2113 Acknowledgments 2115 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 2116 Govidan of ISI for their work on NBMA ARP and the original NHRP 2117 draft, which served as the basis for this work. Russell Gardo of 2118 IBM, John Burnett of Adaptive, Dennis Ferguson of ANS, Joel Halpern 2119 of Newbridge, Paul Francis of NTT, Tony Li and Yakov Rekhter of 2120 cisco, and Grenville Armitage of Bellcore should also be acknowledged 2121 for comments and suggestions that improved this work substantially. 2122 We would also like to thank the members of the ION working group of 2123 the IETF, whose review and discussion of this document have been 2124 invaluable. 2126 Authors' Addresses 2128 James V. Luciani Dave Katz 2129 Bay Networks cisco Systems 2130 3 Federal Street 170 W. Tasman Dr. 2131 Mail Stop: BL3-04 San Jose, CA 95134 USA 2132 Billerica, MA 01821 Phone: +1 408 526 8284 2133 Phone: +1 508 439 4734 Email: dkatz@cisco.com 2134 Email: luciani@baynetworks.com 2136 David Piscitello Bruce Cole 2137 Core Competence cisco Systems 2138 1620 Tuckerstown Road 170 W. Tasman Dr. 2139 Dresher, PA 19025 USA San Jose, CA 95134 USA 2140 Phone: +1 215 830 0692 Phone: +1 408 526 4000 2141 Email: dave@corecom.com Email: bcole@cisco.com