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