idnits 2.17.1 draft-ietf-rolc-nhrp-02.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-24) 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 208: '...P request. NHSs MUST never respond to...' RFC 2119 keyword, line 240: '...ests and replies MUST never cross the ...' RFC 2119 keyword, line 254: '...ing in the reply MUST be cached in all...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 25, 1994) is 10835 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) ** Downref: Normative reference to an Experimental draft: draft-ietf-rolc-nbma-arp (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-03) exists of draft-katz-router-alert-00 Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Routing over Large Clouds Working Group Dave Katz 2 INTERNET-DRAFT (cisco Systems) 3 David Piscitello 4 (Core Competence, Inc.) 5 August 25, 1994 7 NBMA Next Hop Resolution Protocol (NHRP) 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress." 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any Internet 24 Draft. 26 Abstract 28 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 29 NHRP can be used by a source station (host or router) connected to a 30 Non-Broadcast, Multi-Access (NBMA) network to determine the IP and 31 NBMA network addresses of the "NBMA next hop" towards a destination 32 station. If the destination is connected to the NBMA network, then 33 the NBMA next hop is the destination station itself. Otherwise, the 34 NBMA next hop is the egress router from the NBMA network that is 35 "nearest" to the destination station. Although this document focuses 36 on NHRP in the context of IP, the technique is applicable to other 37 network layer protocols as well. 39 This document is intended to be a functional superset of the NBMA 40 Address Resolution Protocol (NARP) documented in [1]. 42 1. Introduction 44 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 45 (a host or router), wishing to communicate over a Non-Broadcast, 46 Multi-Access (NBMA) network, to determine the IP and NBMA addresses 47 of the "NBMA next hop" toward a destination station. A network can 48 be non-broadcast either because it technically doesn't support 49 broadcasting (e.g., an X.25 network) or because broadcasting is not 50 feasible for one reason or another (e.g., an SMDS broadcast group or 51 an extended Ethernet would be too large). If the destination is 52 connected to the NBMA network, then the NBMA next hop is the 53 destination station itself. Otherwise, the NBMA next hop is the 54 egress router from the NBMA network that is "nearest" to the 55 destination station. 57 An NBMA network may, in general, consist of multiple logically 58 independent IP subnets (LISs), defined in [3] and [4] as having the 59 following properties: 61 1) All members of a LIS have the same IP network/subnet number 62 and address mask. 64 2) All members within a LIS are directly connected to the same 65 NBMA network. 67 3) All members outside of the LIS are accessed via a router. 69 IP routing described in [3] and [4] only resolves the next hop 70 address if the destination station is a member of the same LIS as the 71 source station; otherwise, the source station must forward packets to 72 a router that is a member of multiple LIS's. In multi-LIS 73 configurations, hop-by-hop IP routing may not be sufficient to 74 resolve the "NBMA next hop" toward the destination station, and IP 75 packets may traverse the NBMA network more than once. 77 NHRP describes a routing method that obviates the need for LISs. 78 With NHRP, once the NBMA next hop has been resolved, the source may 79 either start sending IP packets to the destination (in a 80 connectionless NBMA network such as SMDS) or may first establish a 81 connection to the destination with the desired bandwidth and QOS 82 characteristics (in a connection-oriented NBMA network such as ATM). 84 NHRP in its most basic form provides a simple IP-to-NBMA-address 85 binding service. This may be sufficient for hosts which are directly 86 connected to an NBMA network, allowing for straightforward 87 implementations in NBMA stations. Optional services extend this 88 functionality to include loop detection, sanity checks, diagnostics, 89 security features, and fallback capabilities, providing improved 90 robustness and functionality. 92 NHRP supports both a server-based style of deployment and a 93 ubiquitous "fabric", consisting of NHRP-capable routers. The 94 server-based approach requires a smaller number of machines to 95 support NHRP, but requires significantly more manual configuration. 97 Address resolution techniques such as those described in [3] and [4] 98 may be in use when NHRP is deployed. ARP servers and services over 99 NBMA networks may be required to support hosts that are not capable 100 of dealing with any model for communication other than the LIS model, 101 and deployed hosts may not implement NHRP but may continue to support 102 ARP variants such as those described in [3] and [4]. NHRP is 103 designed to eliminate the suboptimal routing that results from the 104 LIS model, and can be deployed in a non-interfering manner alongside 105 existing ARP services. 107 2. Protocol Overview 109 In this section, we briefly describe how a source S (which 110 potentially can be either a router or a host) uses NHRP to determine 111 the "NBMA next hop" to destination D. 113 For administrative and policy reasons, a physical NBMA network may be 114 partitioned into several, disjoint "Logical NBMA networks". A 115 Logical NBMA network is defined as a collection of hosts and routers 116 that share ulfiltered data link connectivity over an NBMA network. 117 "Unfiltered data link connectivity" refers to the absence of closed 118 user groups, address screening or similar features that may be used 119 to prevent direct communication between stations connected to the 120 same NBMA network. (Hereafter, unless otherwise specified, we use 121 NBMA network to mean logical NBMA network.) 123 Placed within the NBMA network are one or more entities that 124 implement the NHRP protocol, otherwise known as "Next Hop Servers" 125 (NHSs). Each NHS serves a set of destination hosts, which may or may 126 not be directly connected to the NBMA network. NHSs cooperatively 127 resolve the NBMA next hop within their logical NBMA network. In 128 addition to the NHRP, NHSs participate in protocols used to 129 disseminate routing information across (and beyond the boundaries of) 130 the NBMA network, and may support "classical" ARP service as well. 132 An NHS maintains a "next-hop resolution" cache, which is a table of 133 address mappings (IP-to-NBMA address). This table can be constructed 134 from information gleaned from NHRP Register packets (see Section 135 5.4), extracted from NHRP replies that traverse NHS as they are 136 forwarded toward the NHRP request initiator, or through mechanisms 137 outside the scope of this document (examples of such mechanisms 138 include ARP [2, 3, 4] and pre-configured tables). 140 A host or router that is not an NHRP speaker must be configured with 141 the identity of the NHS which serves it (see Configuration, Section 142 4). 144 [Note: for NBMA networks that offer group or multicast addressing 145 features, it may be desirable to configure stations with a group 146 identity for NHSs, i.e., addressing information that would solicit a 147 response from "all NHSs". The means whereby a group of NHSs divide 148 responsibilities for next hop resolution are not described here.] 150 The protocol proceeds as follows. An event occurs triggering station 151 S to want to resolve the NBMA address of a path to D. This is most 152 likely to be when data packet addressed to station D is to be emitted 153 from station S (either because station S is a host, or station S is a 154 transit router), but could also be triggered by other means (a 155 resource reservation request, for example). Station S first 156 determines the next hop to station D through normal routing processes 157 (for a host, this may simply be the default router; for routers, this 158 is the "next hop" to the destination IP address). If the next hop is 159 reachable through its NBMA interface, S constructs an NHRP request 160 packet (see Section 5.2) containing station D's IP address as the 161 (target) destination address, S's own IP address as the source 162 address (NHRP request initiator), and station S's NBMA addressing 163 information. Station S may also indicate whether it prefers an 164 authoritative reply (i.e., station S only wishes to receive a reply 165 from the NHS-speaker that maintains the NBMA-to-IP address mapping 166 for this destination). Station S encapsulates the NHRP request 167 packet in an IP packet containing as its destination address the IP 168 address of its NHS. This IP packet is emitted across the NBMA 169 interface to the NBMA address of the NHS. 171 If the NHRP request is triggered by a data packet, station S may 172 choose to dispose of the data packet While awaiting an NHRP reply in 173 one of the following ways: 175 (a) Drop the packet 176 (b) Retain the packet until the reply arrives and a more optimal 177 path is available 178 (c) Forward the packet along the routed path toward D 180 The choice of which of the above to perform is a local policy matter, 181 though option (c) is an attractive default. 183 When the NHS receives an NHRP request, it checks to see if it 184 "serves" station D, i.e., the NHS checks to see if it has a "next 185 hop" entry for D in its next-hop resolution cache. If so, the NHS 186 resolves station D's NBMA address. The NHS then generates a positive 187 NHRP reply on D's behalf. The NHRP reply packet contains the next hop 188 IP and NBMA address for station D and is sent back to S. The reply 189 generated in this case is marked as "authoritative". (Note that if 190 station D is not on the NBMA network, the next hop IP address will be 191 that of the egress router through which packets for station D are 192 forwarded.) 194 If the NHS does not serve D, the NHS forwards the NHRP request to 195 another NHS. (Mechanisms for determining how to forward the NHRP 196 request are discussed in Section 3, Modes of Deployment.) If this 197 NHS serves D, it generates a positive NHRP reply on D's behalf. 198 (NHRP replies in this scenario are always marked as "authoritative".) 199 NHRP replies usually traverse the same sequence of NHSs as the NHRP 200 request (in reverse order). This is typically a consequence of 201 having symmetric routing. An NHS receiving an NHRP reply may cache 202 the NBMA next hop information contained therein. To a subsequent 203 NHRP request, this NHS may respond with the cached, non- 204 authoritative, NBMA next hop information or with cached negative 205 information. Non-authoritative NHRP replies are distinguished from 206 authoritative replies so that if a communication attempt based on 207 non-authoritative information fails, a source station can choose to 208 send an authoritative NHRP request. NHSs MUST never respond to 209 authoritative NHRP requests with cached information. 211 [Note: An NHRP reply can be returned directly to the NHRP request 212 initiator, i.e., without traversing the list of NHSs that forwarded 213 the request, if all of the following criteria are satisfied: 215 (a) Direct communication is available via datagram transfer 216 (e.g., SMDS) or the NHS has an existing virtual circuit 217 connection to the NHRP request initiator or is permitted 218 to open one. 219 (b) The NHRP request initiator has not included the NHRP 220 Reverse NHS record Option (see Section 5.6.5). 221 (c) The NHRP request initiator has not included the destination 222 mask option (see Section 5.6.1). 223 (d) The authentication policy in force permits direct 224 communication between the NHS and the NHRP request 225 initiator. 227 The purpose of allowing an NHS to reply directly is to reduce 228 response time. A consequence of allowing a direct reply is that 229 NHSs that would under normal circumstances be traversed by the 230 reply would not cache next hop information contained therein.] 232 The process of forwarding the NHRP request is repeated until the 233 request is satisfied, or an error occurs (e.g., no NHS in the NBMA 234 network can resolve the request.) If the determination is made that 235 station D's next hop cannot be resolved, a negative reply is 236 returned. This occurs when (a) no next-hop resolution information is 237 available for station D from any NHS, or (b) an NHS is unable to 238 forward the NHRP request (e.g., connectivity is lost). 240 NHRP requests and replies MUST never cross the borders of a logical 241 NBMA network (an explicit NBMA network identifier may be included as 242 an option in the NHRP request, see section 5.6.2). Thus, IP traffic 243 out of and into a logical NBMA network always traverses an IP router 244 at its border. Network layer filtering can then be implemented at 245 these border routers. 247 NHRP optionally provides a mechanism to aggregate NBMA next hop 248 information in NHS caches. Suppose that router X is the NBMA next 249 hop from station S to station D. Suppose further that X is an egress 250 router for all stations sharing an IP address prefix with station D. 251 When an NHRP reply is generated in response to a request, the 252 responder may augment the IP address of station D with a mask 253 defining this prefix (see Section 5.6.1). The prefix to egress 254 router mapping in the reply MUST be cached in all NHSs on the path of 255 the reply. A subsequent (non-authoritative) NHRP request for some 256 destination that shares an IP address prefix with D can be satisfied 257 with this cached information. 259 To dynamically detect link-layer filtering in NBMA networks (e.g., 260 X.25 closed user group facility, or SMDS address screens), as well as 261 to provide loop detection and diagnostic capabilities, NHRP 262 optionally incorporates a "Route Record" in requests and replies (see 263 Sections 5.6.4 and 5.6.5). The Route Record options contain the 264 network (and link layer) addresses of all intermediate NHSs between 265 source and destination (in the forward direction) and between 266 destination and source (in the reverse direction). When a source 267 station is unable to communicate with the responder, it may attempt 268 to do so successively with other link layer addresses in the Route 269 Record until it succeeds (if authentication policy permits such 270 action). This approach can find the optimal best hop in the presence 271 of link-layer filtering (which may be source/destination sensitive, 272 for instance, without necessarily creating separate logical NBMA 273 networks) or link-layer congestion (especially in connection-oriented 274 media). 276 3. Modes of Deployment 278 NHRP supports two deployment modes of operation: "server" and 279 "fabric" modes. The two modes differ only in the way NHRP packets 280 are propagated, which is driven by differences in configuration. 282 It is desirable that hosts attached directly to the NBMA network have 283 no knowledge of whether NHRP is deployed in "server" or "fabric" 284 modes, so that a change in deployment strategy can be done within a 285 single administration, transparently to hosts. For this reason, host 286 configuration is invariant between the two cases. Note that 287 irrespective of which mode is deployed, NHRP clients must nominally 288 be configured with the NBMA (and IP) address of at least one NHS. In 289 practice, a host's default router should also be its NHS. 291 Server Mode 293 In "server" mode, the expectation is that a small number of NHSs 294 will be fielded in an NBMA network. This may be appropriate in 295 networks containing routers that do not support NHRP, or networks 296 that have large numbers of directly-attached hosts (and relatively 297 few routers). Server mode assumes that NHRP is very loosely 298 coupled with IP routing, and that the path taken by NHRP requests 299 has little to do with the path taken by IP data packets routed to 300 the desired destination. 302 [Note: This is the likely scenario for initial deployment of NHRP. 303 It is also likely that single and Multi-LIS configurations using 304 either group-addressed ARP (in the case of SMDS) or ARP servers (in 305 the case of ATM or SMDS) may already be in place.] 307 Server mode uses static configuration of NHS identity. The client 308 station must be configured with the IP address of one or more NHSs, 309 and there must be a path to that NHS (either directly, in which 310 case the NHS's NBMA address must be known, or indirectly, through a 311 router whose NBMA address is known). If there are multiple NHSs, 312 they must be configured with each others' addresses, the identities 313 of the destinations that each of them serves, and optionally a 314 logical NBMA network identifier. (This static configuration 315 requirement, which may involve authentication as well as addressing 316 information, tends to limit such deployments to a very small number 317 of NHSs.) 319 If the NBMA network offers a group addressing or multicast feature, 320 the client (station) may be configured with a group address 321 assigned to the group of next-hop servers. The client might then 322 submit NHRP requests to the group address, eliciting a response 323 from one or more NHSs, depending on the response strategy selected. 324 Note that the constraints described in Section 2 regarding direct 325 replies may apply. 327 The servers can also be deployed with the group or multicast 328 address of their peers, and an NHS might use this as a means of 329 forwarding NHRP requests it cannot satisfy to its peers. This 330 might elicit a response (to the NHS) from one or more NHSs, 331 depending on the response strategy. The NHS would then forward the 332 NHRP reply to the NRHP request originator. The purpose of using 333 group addressing or a similar multicast mechanism in this scenario 334 would be to eliminate the need to preconfigure each NHS in a 335 logical NBMA network with both the individual identities of other 336 NHSs as well as the destinations they serve. It reduces the number 337 of NHSs that might be traversed to process an NHRP request (in 338 those configurations where NHSs either respond or forward via the 339 multicast, only two NHSs would be traversed), and allows the NHS 340 that serves the NHRP request originator to cache next hop 341 information associated with the reply (again, within the 342 constraints described in Section 2). 344 The NHRP request packet's destination IP address is set by the 345 source station to the first-hop NHS's IP address. If the addressed 346 NHS does not serve the destination, the NHRP request is forwarded 347 to the IP address of the NHS that serves the destination. 349 The responding NHS uses the source address from within the NHRP 350 packet (not the source address of the IP packet) as the IP 351 destination of the NHRP reply. 353 Fabric Mode 355 In "fabric" mode, it is expected that NHRP-capable routers are 356 ubiquitous throughout the NBMA network, and that NHSs acquire 357 knowledge about destinations other NHSs serve as a direct 358 consequence of participating in intradomain and interdomain routing 359 protocol exchange. In particular, it is expected that an NHS 360 serving a particular destination is guaranteed to lie along the 361 routed path to that destination. In practice, this means that all 362 egress routers must double as NHSs serving the destinations beyond 363 them, and that hosts on the NBMA network are served by routers that 364 double as NHSs. 366 Fabric mode leverages a routed infrastructure that "overlays" the 367 NBMA network. The source station passes the NHRP request to the 368 router which serves as the next hop toward the destination. Each 369 router in turn forwards the NHRP request toward the destination. 370 Eventually, the NHRP request arrives at a router that is acting as 371 an NHS serving the destination (or the destination itself, if it is 372 an NHRP-speaker), which generates the NHRP reply. 374 If the source station is a host, it sets the IP destination address 375 of the NHRP request to the first-hop NHS/router (so that hosts 376 needn't know the mode in which the network is running). If the 377 source station is a router, the destination IP address may be set 378 either to the next-hop router or to the ultimate destination being 379 resolved. Each NHS/router examines the NHRP request packet on its 380 way toward the destination, optionally modifying it on the way 381 (such as updating the Forward Record option). If an NHS/router 382 receives an NHRP packet addressed to itself to which it cannot 383 reply (because it does not serve the destination directly), it will 384 forward the NHRP request with the destination IP address set to the 385 ultimate destination (thus allowing invariant host behavior). 386 Eventually, the NHRP packet will arrive at the router/NHS that 387 serves the destination (which will return a positive NHRP reply) or 388 it will arrive at a router/NHS that has no route to the destination 389 (which will return a negative NHRP reply), or it may arrive at a 390 router/NHS that cannot reach the NHS that serves the destination 391 due to a loss of reachability among the NHSs (in which case the 392 router will return a negative NHRP reply). 394 The procedural difference between server mode and fabric mode is 395 reduced to deciding how to update the destination address in the IP 396 packet carrying the NHRP request. 398 Note that addressing the NHRP request to the ultimate destination 399 allows for networks that do not have NHSs deployed in all routers; 400 typically a very large NBMA network might only deploy NHSs in 401 egress routers, and not in transit routers. 403 4. Configuration 405 Stations 407 To participate in NHRP, a station connected to an NBMA network 408 should be configured with the IP and NBMA address(es) of its NHS(s) 409 (alternatively, it should be configured with a means of acquiring 410 them, i.e., the group address that members of a NHS group use for 411 the purpose of address or next-hop resolution.) The NHS(s) may be 412 physically located on the stations's default or peer routers, so 413 their addresses may be obtained from the station's IP forwarding 414 table. If the station is attached to several link layer networks 415 (including logical NBMA networks), the station should also be 416 configured to receive routing information from its NHS(s) and peer 417 routers so that it can determine which IP networks are reachable 418 through which link layer networks. 420 Next Hop Servers 422 An NHS is configured with its own identity, a set of IP address 423 prefixes that correspond to the IP addresses of the stations it 424 serves, a logical NBMA network identifier (see Section 5.6.2), and 425 in the case of "server" mode, the identities of other NHSs in the 426 same logical NBMA network. If a served station is attached to 427 several link layer networks, the NHS may also need to be configured 428 to advertise routing information to such stations. 430 If an NHS acts as an egress router for stations connected to other 431 link layer networks than the NBMA network, the NHS must, in 432 addition to the above, be configured to exchange routing 433 information between the NBMA network and these other link layer 434 networks. 436 In all cases, routing information is exchanged using conventional 437 intra-domain and/or inter-domain routing protocols. 439 The NBMA addresses of the stations served by the NHS may be learned 440 via NHRP Register packets or manual configuration. 442 5. Packet Formats 444 This section describes the format of NHRP packets. 446 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 447 Options Part. The Fixed Part is common to all NHRP packet types. 448 The Mandatory Part must be present, but varies depending on packet 449 type. The Options Part also varies depending on packet type, and 450 need not be present. 452 The length of the Fixed Part is fixed at 8 octets. The length of the 453 Mandatory Part is carried in the Fixed Part. The length of the 454 Options Part is implied by the total packet length (Internet datagram 455 total length minus IP header length minus NHRP fixed part length 456 minus NHRP mandatory part length). 458 Note that since the lengths of all fields are self-encoding, it is 459 permissible to pad the Mandatory and Options parts with arbitrary 460 numbers of trailing zero octets to achieve any desired alignment. 461 Note however that any padding in the Mandatory Part must be included 462 in the Mandatory Part Length. 464 NHRP packets are carried in IP packets as protocol type 54 (decimal). 465 NHSs may increase the size of an NHRP packet as a result of option 466 processing. IP datagrams containing NHRP packets must have the Don't 467 Fragment bit set. 469 Fields marked "unused" must be set to zero on transmission, and 470 ignored on receipt. 472 Most packet types have both network layer protocol-independent fields 473 and protocol-specific fields. The protocol-independent fields always 474 come first in the packet, and the Protocol ID field qualifies the 475 format of the protocol-specific fields. The protocol-specific fields 476 defined in this document are for IPv4 only; formats of protocol- 477 specific fields for other protocols are for further study. 479 5.1 NHRP Fixed Header 481 The NHRP Fixed Header is present in all NHRP packets. It contains 482 the basic information needed to parse the rest of the packet. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Version | Hop Count | Checksum | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Type | Unused | Mandatory Part Length | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Version 493 The NHRP version number. Currently this value is 1. 495 Hop Count 496 The Hop count indicates the maximum number of NHSs that an NHRP 497 packet is allowed to traverse before being discarded. 499 Checksum 500 The standard IP checksum over the entire NHRP packet (starting with 501 the fixed header). If only the hop count field is changed, the 502 checksum is adjusted without full recomputation. The checksum is 503 completely recomputed when other header fields are changed. 505 Type 506 The NHRP packet type: Request, Response, Register, or Error 507 Indication (see below). 509 Mandatory Part Length 510 The length in octets of the Mandatory Part. This length does not 511 include the Fixed Header. 513 5.2 NHRP Request 515 The NHRP Request packet has a Type code of 1. The Mandatory Part has 516 the following format: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |Q|S|A|P| Unused | Protocol ID | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Request ID | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 (IPv4-Specific) 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Destination IP address | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Source IP address | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Holding Time | Unused | Address Type | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | NBMA Length | Source NBMA Address (variable length) | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Q 538 Set if the Requestor is a router; clear if the requestor is a 539 host. 541 S 542 Unused (zero on transmit) 544 A 545 A response to an NHRP request may contain cached information. If 546 an authoritative answer is desired, then this bit ("Authoritative") 547 should be set. If non-authoritative (cached) information is 548 acceptable, this bit should be clear. 550 P 551 Unused (zero on transmit) 553 Protocol ID 554 Specifies the network layer protocol for which we are obtaining 555 routing information. This value also qualifies the structure of 556 the remainder of the Mandatory Part. For IPv4, the Protocol ID is 557 hexadecimal 800 (decimal 2048). Protocol ID values for other 558 network layer protocols are for future study. 560 Request ID 561 A value chosen by the source to aid in matching requests with 562 replies. This value could also be sent across a virtual circuit 563 (in SVC environments) to aid in matching NHRP transactions with 564 virtual circuits (this use is for further study). 566 Destination and Source IP Addresses 567 Respectively, these are the IP addresses of the station for which 568 the NBMA next hop is desired, and the NHRP request initiator. 570 Source Holding Time, Address Type, NBMA Length, and NBMA Address 571 The Holding Time field specifies the number of seconds for which 572 the source NBMA information is considered to be valid. Cached 573 information shall be discarded when the holding time expires. 575 The Address Type field specifies the type of NBMA address 576 (qualifying the NBMA address). Possible address types are . 578 The NBMA length field is the length of the NBMA address of the 579 source station in bits. The NBMA address field itself is zero- 580 filled to the nearest 32-bit boundary. 582 5.3 NHRP Reply 584 The NHRP Reply packet has a type code of 2. The Mandatory Part has 585 the following format: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |Q|S|A|P| Unused | Protocol ID | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Request ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 (IPv4-Specific) 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Destination IP address | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Source IP address | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Next-hop IP address | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Holding Time | Preference | Address Type | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | NBMA Length | NBMA Address (variable length) | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 ... 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Next-hop IP address | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Holding Time | Preference | Address Type | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | NBMA Length | NBMA Address (variable length) | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 Q 619 Copied from the NHRP Request. Set if the Requestor is a router; 620 clear if the requestor is a host. 622 S 623 Set if the next hop identified in the reply is a router; clear if 624 the next hop is a host. 626 A 627 Set if the reply is authoritative; clear if the reply is non- 628 authoritative. 630 P 631 Set if the reply is positive; clear if the reply is negative. 633 An NHS is not allowed to reply to an NHRP request for authoritative 634 information with cached information, but may do so for an NHRP 635 Request which indicates a request for non-authoritative information. 636 An NHS may reply to an NHRP request for non-authoritative information 637 with authoritative information. 639 Protocol ID 640 Specifies the network layer protocol for which we are obtaining 641 routing information. This value also qualifies the structure of 642 the remainder of the Mandatory Part. For IPv4, the Protocol ID is 643 hexadecimal 800 (decimal 2048). Protocol ID values for other 644 network layer protocols are for future study. 646 Request ID 647 Copied from the NHRP Request. 649 Destination IP Address 650 The address of the target station (copied from the corresponding 651 NHRP Request). 653 Source IP Address 654 The address of the initiator of the request (copied from the 655 corresponding NHRP Request). 657 Next-hop entry 658 A Next-hop entry consists of the following fields: a 32-bit Next- 659 hop IP Address, a 16-bit Holding Time, an 8-bit Preference, an 8- 660 bit Address Type, an 8-bit NBMA Length, and an NBMA Address whose 661 length is the value of the NBMA length field. 663 The Next-hop IP Address specifies the IP address of the next hop. 664 This will be the address of the destination host if it is directly 665 attached to the NBMA network, or the egress router if it is not 666 directly attached. 668 The Holding Time field specifies the number of seconds for which 669 the associated Next-hop entry inforamtion is considered to be 670 valid. Cached information shall be discarded when the holding time 671 expires. (Holding time is to be specified for both positive and 672 negative replies). 674 The Preference field specifies the preference of the Next-hop 675 entry, relative to other Next-hop entries in this NHRP Reply 676 packet. Higher values indicate more preferable Next-hop entries. 678 The Address Type field specifies the type of NBMA address 679 (qualifying the NBMA address). Possible address types are . 681 The NBMA length field specifies the length of the NBMA address of 682 the destination station in bits. The NBMA address field itself is 683 zero-filled to the nearest 32-bit boundary. For negative replies, 684 the Holding Time field is relevant; however, the preference, 685 Address Type, and NBMA length fields must be zero, and the NBMA 686 Address shall not be present. 688 There may be multiple Next-hop entries returned in the reply (as 689 implied by the Mandatory Part Length). The preference values are 690 used to select the preferred entry. The same next-hop IP address 691 may be associated with multiple NBMA addresses. Load-splitting may 692 be performed over the addresses, given equal preference values, and 693 the alternative addresses may be used in case of connectivity 694 failure in the NBMA network (such as a failed call attempt in 695 connection-oriented NBMA networks). 697 5.4 NHRP Register 699 The NHRP Register packet is sent from a station to an NHS to notify 700 the NHS of the station's NBMA address. It has a Type code of 3. The 701 Mandatory Part has the following format: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Unused | Protocol ID | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 (IPv4-Specific) 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Source IP address | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Holding Time | Unused | Address Type | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | NBMA Length | NBMA Address (variable length) | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 Protocol ID 719 Specifies the network layer protocol for which we are obtaining 720 routing information. This value also qualifies the structure of 721 the remainder of the Mandatory Part. For IPv4, the Protocol ID is 722 hexadecimal 800 (decimal 2048). Protocol ID values for other 723 network layer protocols are for future study. 725 Source IP Address 726 The IP address of the station wishing to register its NBMA address 727 with an NHS. 729 Source Holding Time, Address Type, NBMA Length, and NBMA Address 730 The Holding Time field specifies the number of seconds for which 731 the source NBMA information is considered to be valid. Cached 732 information shall be discarded when the holding time expires. 734 The Address Type field specifies the type of NBMA address 735 (qualifying the NBMA address). Possible address types are . 737 The NBMA length field is the length of the NBMA address of the 738 source station in bits. The NBMA address itself is zero-filled to 739 the nearest 32-bit boundary. 741 This packet is used to register a station's IP and NBMA addresses 742 with its configured NHS. This allows static configuration 743 information to be reduced; the NHSs need not be configured with the 744 identities of all of the stations that they serve. 746 It is possible that a misconfigured station will attempt to register 747 with the wrong NHS (i.e., one that cannot serve it due to policy 748 constraints or routing state). If this is the case, the NHS must 749 reply with an Error Indication of type Can't Serve This Address. 751 If an NHS cannot serve a station due to a lack of resources, the NHS 752 must reply with an Error Indication of type Registration Overflow. 754 5.5 NHRP Error Indication 756 The NHRP Error Indication is used to convey error indications to the 757 initiator of an NHRP Request packet. It has a type code of 4. The 758 Mandatory Part has the following format: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Error Code | Error Offset | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 +-+-+-+-+-+-+-+ Contents of NHRP Packet in error +-+-+-+-+-+-+-+ 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 Error Code 771 An error code indicating the type of error detected, chosen from 772 the following list: 774 1 - Unrecognized Option 775 2 - Network ID Mismatch 776 3 - NHRP Loop Detected 777 4 - Can't Serve This Address 778 5 - Registration Overflow 779 6 - Server Unreachable 780 7 - Protocol Error 781 8 - NHRP fragmentation failure 783 Error Offset 784 The offset in octets into the original NHRP packet, starting at the 785 NHRP Fixed Header, at which the error was detected. 787 The destination IP address of an NHRP Error Indication shall be set 788 to the IP address of the initiator of the original NHRP Request (as 789 extracted from the NHRP Request or NHRP Reply). 791 An Error Indication packet shall never be generated in response to 792 another Error Indication packet. When an Error Indication packet is 793 generated, the offending NHRP packet shall be discarded. In no case 794 should more than one Error Indication packet be generated for a 795 single NHRP packet. 797 5.6 Options Part 799 The Options Part, if present, carries one or more options in {Type, 800 Length, Value} triplets. Options are only present in a Reply if they 801 were present in the corresponding Request; therefore, minimal NHRP 802 station implementations that do not act as an NHS and do not transmit 803 options need not be able to receive them. Such an implementation 804 that receives a packet with options shall return an Error Indication 805 of type Unrecognized Option. 807 Options are typically protocol-specific, as noted. 809 Options have the following format: 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 |O| Type | Length | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Value... | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 O 820 "Optional." If set, and the NHS does not recognize the type code, 821 the option may safely be ignored. If clear, and the NHS does not 822 recognize the type code, the NHRP request is considered in error. 823 (See below for details.) 825 Type 826 The option type code (see below). The option type is not qualified 827 by the Optional bit, but is orthogonal to it. 829 Length 830 The length in octets of the value (not including the Type and 831 Length fields; a null option will have only an option header and a 832 length of zero). 834 Each option is padded with zero octets to a 32 bit boundary. This 835 padding is not included in the Length field. 837 Options may occur in any order, but any particular option type may 838 occur only once in an NHRP packet. 840 The Optional bit provides for a means to extend the option set. If 841 it is clear, the NHRP request cannot be satisfied if the option is 842 unrecognized, so the responder must return an Error Indication of 843 type Unrecognized Option. If set, the option can be safely ignored. 844 In this case, the offending option should simply be returned 845 unchanged in the NHRP Reply. 847 If a transit NHS (one which is not going to generate a reply) detects 848 an unrecognized option, it shall ignore the option, and if the 849 Optional bit is clear, must not cache the information (in the case of 850 a reply) and must not identify itself as an egress router (in the 851 Forward Record or Reverse Record options). Effectively, this means 852 that a transit NHS that doesn't understand an option with the 853 Optional bit clear must not participate in any way in the protocol 854 exchange, other than acting as a forwarding agent for the request. 856 5.6.1 Destination Mask Option (IPv4-Specific) 858 Optional = 0 859 Type = 1 860 Length = 4 862 This option is used to indicate that the information carried in an 863 NHRP Reply pertains to an equivalence class of destinations rather 864 than just the destination IP address specified in the request. All 865 addresses that match the destination IP address in the bit positions 866 for which the mask has a one bit are part of the equivalence class. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Destination Mask | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 If an initiator would like to receive this equivalence information, 875 it shall add this option to the NHRP Request with a value of 876 255.255.255.255. The responder shall copy the option to the NHRP 877 Reply and modify the mask appropriately. 879 5.6.2 NBMA Network ID Option (Protocol-Independent) 881 Optional = 0 882 Type = 2 883 Length = variable 885 This option is used to carry one or more identifiers for the NBMA 886 network. This can be used as a validity check to ensure that the 887 request does not leave a particular NBMA network. The option is 888 placed in an NHRP Request packet by the initiator with an ID value of 889 zero; the first NHS fills in the field with the identifier(s) for 890 the NBMA network. 892 Multiple NBMA Network IDs may be used as a transition mechanism while 893 NBMA Networks are being split or merged. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | NBMA Network ID | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 ... 902 Each identifier consists of a 32 bit globally unique value assigned 903 to the NBMA network. This value should be chosen from the IP address 904 space administered by the operators of the NBMA network. This value 905 is used for identification only, not for routing or any other 906 purpose. 908 Each NHS processing an NHRP Request shall verify these values. If 909 none of the values matches the NHS's NBMA Network ID, the NHS shall 910 return an Error Indication of type "Network ID Mismatch" and discard 911 the NHRP Request. 913 When an NHS is building an NHRP Reply and the NBMA Network ID option 914 is present in the NHRP Request, the NBMA Network ID option shall be 915 copied from the Request to the Reply. 917 Each NHS processing an NHRP Reply shall verify the value carried in 918 the NBMA Network ID option, if present. If none of the values 919 matches the NHSs NBMA Network ID, the NHS shall return an Error 920 Indication of type "Network ID Mismatch" and discard the NHRP Reply. 922 5.6.3 Responder Address Option (IPv4-Specific) 924 Optional = 0 925 Type = 3 926 Length = 4 928 This option is used to determine the IP address of the NHRP 929 Responder, that is, the entity that generates the NHRP Reply packet. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Responder's IP Address | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 If a requestor desires this information, it shall include this 938 option, with a value of zero, in the NHRP Request packet. 940 If an NHS is generating an NHRP Reply packet in response to a request 941 containing this option, it shall include this option, containing its 942 IP address, in the NHRP Reply. If an NHS has more than one IP 943 address, it shall use the same IP address consistently in all of the 944 Responder Address, Forward NHS Record, and Reverse NHS Record 945 options. 947 If an NHRP Reply packet being forwarded by an NHS contains the IP 948 address of that NHS in the Responder Address Option, the NHS shall 949 generate an Error Indication of type "NHRP Loop Detected" and discard 950 the Reply. 952 If an NHRP Reply packet is being returned by an intermediate NHS 953 based on cached data, it shall place its own address in this option 954 (differentiating it from the address in the Next-hop field). 956 5.6.4 NHRP Forward NHS Record Option (IPv4-Specific) 958 Optional = 0 959 Type = 4 960 Length = variable 962 The NHRP forward NHS record is a list of NHSs through which an NHRP 963 request traverses. Each NHS shall append a Next-hop element 964 containing its IP address to this option. 966 In addition, NHSs that are willing to act as egress routers for 967 packets from the source to the destination shall include information 968 about their NBMA Address. 970 Each Next-hop element is formatted as follows: 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | IP address | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Holding Time | Unused | Address Type | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | NBMA Length | NBMA Address (variable length) | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 IP address 983 The IP address of the NHS. 985 Holding Time 986 The number of seconds for which this information is valid. If a 987 station chooses to use this information as a next-hop entry, it may 988 not be used once the holding timer expires. 990 Address Type, NBMA Length, and NBMA Address 991 The Address Type field specifies the type of NBMA address 992 (qualifying the NBMA address). Possible address types are . 994 The NBMA length field is the length of the NBMA address of the 995 destination station in bits. The NBMA address itself is zero- 996 filled to the nearest 32-bit boundary. 998 NHSs that are not egress routers shall specify an NBMA Length of 999 zero and shall not include an NBMA Address. 1001 If a requestor wishes to obtain this information, it shall include 1002 this option with a length of zero. 1004 Each NHS shall append an appropriate Next-hop element to this option 1005 when processing an NHRP Request. The option length field and NHRP 1006 checksum shall be adjusted as necessary. 1008 The last-hop NHS (the one that will be generating the NHRP Reply) 1009 shall not update this option (since this information will be in the 1010 reply). 1012 If an NHS has more than one IP address, it shall use the same IP 1013 address consistently in all of the Responder Address, Forward NHS 1014 Record, and Reverse NHS Record options. 1016 If an NHRP Request packet being forwarded by an NHS contains the IP 1017 address of that NHS in the Forward NHS Record Option, the NHS shall 1018 generate an Error Indication of type "NHRP Loop Detected" and discard 1019 the Request. 1021 5.6.5 NHRP Reverse NHS Record Option (IPv4-Specific) 1023 Optional = 0 1024 Type = 5 1025 Length = variable 1027 The NHRP reverse NHS record is a list of NHSs through which an NHRP 1028 reply traverses. Each NHS shall append a Next-hop element containing 1029 its IP address to this option. 1031 In addition, NHSs that are willing to act as egress routers for 1032 packets from the source to the destination shall include information 1033 about their NBMA Address. 1035 Each Next-hop element is formatted as follows: 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | IP address | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Holding Time | Unused | Address Type | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | NBMA Length | NBMA Address (variable length) | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 IP address 1048 The IP address of the NHS. 1050 Holding Time 1051 The number of seconds for which this information is valid. If a 1052 station chooses to use this information as a next-hop entry, it may 1053 not be used once the holding timer expires. 1055 Address Type, NBMA Length, and NBMA Address 1056 The Address Type field specifies the type of NBMA address 1057 (qualifying the NBMA address). Possible address types are . 1059 The NBMA length field is the length of the NBMA address of the 1060 destination station in bits. The NBMA address itself is zero- 1061 filled to the nearest 32-bit boundary. 1063 NHSs that are not egress routers shall specify an NBMA Length of 1064 zero and shall not include an NBMA Address. 1066 If a requestor wishes to obtain this information, it shall include 1067 this option with a length of zero. 1069 Each NHS shall append an appropriate Next-hop element to this option 1070 when processing an NHRP Reply. The option length field and NHRP 1071 checksum shall be adjusted as necessary. 1073 The NHS generating the NHRP Reply shall not update this option. 1075 If an NHS has more than one IP address, it shall use the same IP 1076 address consistently in all of the Responder Address, Forward NHS 1077 Record, and Reverse NHS Record options. 1079 If an NHRP Reply packet being forwarded by an NHS contains the IP 1080 address of that NHS in the Reverse NHS Record Option, the NHS shall 1081 generate an Error Indication of type "NHRP Loop Detected" and discard 1082 the Reply. 1084 Note that this information may be cached at intermediate NHSs; if 1085 so, the cached value shall be used when generating a reply. Note 1086 that the Responder Address option may be used to disambiguate the set 1087 of NHSs that actually processed the reply. 1089 5.6.6 NHRP QoS Option 1091 Optional = 0 1092 Type = 6 1093 Length = variable 1095 The NHRP QoS Option is carried in NHRP Request packets to indicate 1096 the desired QoS of the path to the indicated destination. This 1097 information may be used to help select the appropriate NBMA next hop. 1099 It may also be carried in NHRP Register packets to indicate the QoS 1100 to which the registration applies. 1102 The syntax and semantics of this option are TBD; alignment with 1103 resource reservation may be useful. 1105 5.6.7 NHRP Authentication Option 1107 Optional = 0 1108 Type = 7 1109 Length = variable 1111 The NHRP Authentication Option is carried in NHRP packets to convey 1112 authentication information between NHRP speakers. The semantics and 1113 encoding of the authentication option is for further study. 1115 6. Security Considerations 1117 Security considerations are for further study. 1119 7. Discussion 1121 The result of an NHRP request depends on how routing is configured 1122 among the NHSs of an NBMA network. If the destination station is 1123 directly connected to the NBMA network and the NHSs always prefer 1124 NBMA routes over routes via other link layer networks, the NHRP 1125 replies always return the NBMA address of the destination station 1126 itself rather than the NBMA address of some egress router. For 1127 destinations outside the NBMA network, egress routers and routers in 1128 the other link layer networks should exchange routing information so 1129 that the optimal egress router is always found. 1131 When the NBMA next hop toward a destination is not the destination 1132 station itself, the optimal NBMA next hop may change dynamically. 1133 This can happen, for instance, when an egress router nearer to the 1134 destination becomes available. This change can be detected in a 1135 number of ways. First of all, the source station will need to 1136 periodically reissue the NHRP Request at a minimum just prior to the 1137 expiration of the holding timer, and most likely more aggressively 1138 than that. Alternatively, the source can be configured to receive 1139 routing information from its NHSs. When it detects an improvement in 1140 the route to the destination, the source can reissue the NHRP request 1141 to obtain the current optimal NBMA next hop. Source stations that 1142 are routers may choose to establish a routing association with the 1143 egress router, allowing the egress router to explicitly inform the 1144 source about changes in routing (and providing additional routing 1145 information, authentication, etc.) 1147 The dynamic nature of routing impacts caching strategies as well, 1148 since cached information may not be up-to-date. This is especially 1149 an issue when NHSs are deployed in server mode, since the NHSs may 1150 not be privy to routing information. However, stale cached 1151 information may only cause suboptimal routing (choosing the wrong 1152 egress point and taking extra hops across the NBMA network) rather 1153 than causing black holes. Cache management strategies are for 1154 further study. 1156 In addition to NHSs, an NBMA station could also be associated with 1157 one or more regular routers that could act as "connectionless 1158 servers" for the station. The station could then choose to resolve 1159 the NBMA next hop or just send the IP packets to one of its 1160 connectionless servers. The latter option may be desirable if 1161 communication with the destination is short-lived and/or doesn't 1162 require much network resources. The connectionless servers could, of 1163 course, be physically integrated in the NHSs by augmenting them with 1164 IP switching functionality. 1166 NHRP supports portability of NBMA stations. A station can be moved 1167 anywhere within the NBMA network and still keep its original IP 1168 address as long as its NHS(s) remain the same. Requests for 1169 authoritative information will always return the correct link layer 1170 address. 1172 8. Protocol Operation 1174 In this section, we discuss certain operational considerations of 1175 NHRP. 1177 8.1 Router-to-Router Operation 1179 In practice, the initiating and responding stations may be either 1180 hosts or routers. However, there is a possibility under certain 1181 conditions that a stable routing loop may occur if NHRP is used 1182 between two routers. This situation can be avoided if there are no 1183 "back door" paths between the entry and egress router outside of the 1184 NBMA network, and can be ameliorated by periodically reissuing the 1185 NHRP request. If these conditions cannot be satisfied, the use of 1186 NHRP between routers is not recommended. 1188 8.2 Handling of IP Destination Address Field 1190 NHRP packets are self-contained in terms of the IP addressing 1191 information needed for protocol operation--the IP source and 1192 destination addresses in the encapsulating IP header are not used. 1193 However, the setting of the IP destination address field does impact 1194 how NHRP requests are forwarded. 1196 There are essentially three choices in how to set the destination IP 1197 address field at any particular point in the forwarding of an NHRP 1198 request: the ultimate destination being resolved, the next-hop IP 1199 router on the path to the destination, and the next-hop NHS (which 1200 might not be adjacent to the NHS forming the packet header). 1202 The first case, addressing the packet to the destination being 1203 resolved (in the hopes that an NHS lies along the path) is desirable 1204 for at least two reasons. It simplifies configuration (since the 1205 identity of the next NHS need not be known explicitly), and it 1206 simplifies deployment (since the packet will pass silently through 1207 routers that are not NHSs). However, it assumes that the serving NHS 1208 lies along the path to the destination, and it requires NHSs along 1209 the path to examine the packet even though it is not addressed to 1210 them. 1212 The second case, addressing the packet to the next-hop router, is 1213 similar to the first in that it follows the path to the destination, 1214 thus reducing configuration complexity. It furthermore only requires 1215 NHSs to process the packet if they are directly addressed. It too 1216 assumes that the responding NHS is on the path to the destination. 1217 However, it requires that all routers along the path are also NHSs. 1219 The third case, addressing the packet to the next-hop NHS, allows the 1220 NHSs to be independent of routing, and requires only addressed NHSs 1221 to examine the packet. However, there is no reasonable way, other 1222 than manual configuration, to determine the identity of the next hop 1223 NHS if it is not also the next hop IP router (making it option two). 1225 In order to balance all of these issues, the following rules shall be 1226 used when constructing IP packets to carry NHRP requests. 1228 Stations 1230 Stations shall address NHRP packets to the NHS by which they are 1231 served, regardless of whether NHRP has been deployed in Server mode 1232 or Fabric mode. 1234 NHSs 1235 If an NHS receives an NHRP packet in which the IP destination 1236 address does not match any of its own IP addresses, it shall 1237 process the NHRP packet as appropriate, and if it must forward the 1238 NHRP packet to another NHS, shall transmit the packet with the same 1239 IP destination address with which it was received. 1241 If an NHS receives an NHRP packet in which the IP destination 1242 address matches one of its own IP addresses, it shall process the 1243 NHRP packet as appropriate, and if it must forward the NHRP packet 1244 to another NHS, shall set the destination IP address in one of the 1245 following ways: 1247 If there is a configured next-hop NHS for the destination being 1248 resolved (Server mode), it shall transmit the packet with the IP 1249 destination address set to the next-hop NHS. 1251 If there is no configured next-hop NHS (Fabric Mode), it shall 1252 transmit the packet with the IP destination address set to the 1253 address of the destination being resolved, and shall include the 1254 Router Alert option [5] so that intermediate NHS/routers can 1255 examine the NHRP packet. 1257 8.3 Pseudocode 1259 TBD. 1261 References 1263 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 1264 Govindan, draft-ietf-rolc-nbma-arp-00.txt. 1266 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 1268 [3] Classical IP and ARP over ATM, Mark Laubach, Internet Draft. 1270 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 1271 and D. Piscitello, RFC 1209. 1273 [5] IP Router Alert Option, Dave Katz, draft-katz-router-alert- 1274 00.txt. 1276 Acknowledgements 1278 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 1279 Govidan of ISI for their work on NBMA ARP and the original NHRP 1280 draft, which served as a basis for this work. John Burnett of 1281 Adaptive, Dennis Ferguson of ANS, Joel Halpern of Network Systems, 1282 Paul Francis of NTT, and Tony Li of cisco should also be acknowledged 1283 for comments and suggestions that improved this work substantially. 1285 Authors' Addresses 1287 Dave Katz David Piscitello 1288 cisco Systems Core Competence 1289 1525 O'Brien Dr. 1620 Tuckerstown Road 1290 Menlo Park, CA 94025 USA Dresher, PA 19025 USA 1292 Phone: +1 415 688 8284 Phone: +1 215 830 0692 1293 Email: dkatz@cisco.com Email: dave@corecom.com