idnits 2.17.1 draft-ietf-rolc-nhrp-03.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 212: '... NHSs MUST never respond to authorit...' RFC 2119 keyword, line 244: '...ests and replies MUST never cross the ...' RFC 2119 keyword, line 258: '...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 (November 29, 1994) is 10739 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') ** Obsolete normative reference: RFC 1577 (ref. '3') (Obsoleted by RFC 2225) ** Obsolete normative reference: RFC 1700 (ref. '5') (Obsoleted by RFC 3232) == Outdated reference: A later version (-03) exists of draft-katz-router-alert-00 Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing over Large Clouds Working Group Dave Katz 3 INTERNET-DRAFT (cisco Systems) 4 David Piscitello 5 (Core Competence, Inc.) 6 November 29, 1994 8 NBMA Next Hop Resolution Protocol (NHRP) 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any Internet 25 Draft. 27 Abstract 29 This document describes the NBMA Next Hop Resolution Protocol (NHRP). 30 NHRP can be used by a source station (host or router) connected to a 31 Non-Broadcast, Multi-Access (NBMA) network to determine the IP and 32 NBMA network addresses of the "NBMA next hop" towards a destination 33 station. If the destination is connected to the NBMA network, then 34 the NBMA next hop is the destination station itself. Otherwise, the 35 NBMA next hop is the egress router from the NBMA network that is 36 "nearest" to the destination station. Although this document focuses 37 on NHRP in the context of IP, the technique is applicable to other 38 network layer protocols (e.g., IPX, CLNP, Appletalk) as well. 40 This document is intended to be a functional superset of the NBMA 41 Address Resolution Protocol (NARP) documented in [1]. 43 1. Introduction 45 The NBMA Next Hop Resolution Protocol (NHRP) allows a source station 46 (a host or router), wishing to communicate over a Non-Broadcast, 47 Multi-Access (NBMA) network, to determine the IP and NBMA addresses 48 of the "NBMA next hop" toward a destination station. A network can 49 be non-broadcast either because it technically doesn't support 50 broadcasting (e.g., an X.25 network) or because broadcasting is not 51 feasible for one reason or another (e.g., an SMDS multicast group or 52 an extended Ethernet would be too large). If the destination is 53 connected to the NBMA network, then the NBMA next hop is the 54 destination station itself. Otherwise, the NBMA next hop is the 55 egress router from the NBMA network that is "nearest" to the 56 destination station. 58 An NBMA network may, in general, consist of multiple logically 59 independent IP subnets (LISs), defined in [3] and [4] as having the 60 following properties: 62 1) All members of a LIS have the same IP network/subnet number 63 and address mask. 65 2) All members within a LIS are directly connected to the same 66 NBMA network. 68 3) All members outside of the LIS are accessed via a router. 70 IP routing described in [3] and [4] only resolves the next hop 71 address if the destination station is a member of the same LIS as the 72 source station; otherwise, the source station must forward packets to 73 a router that is a member of multiple LIS's. In multi-LIS 74 configurations, hop-by-hop IP routing may not be sufficient to 75 resolve the "NBMA next hop" toward the destination station, and IP 76 packets may traverse the NBMA network more than once. 78 NHRP describes a routing method that obviates the need for LISs. 79 With NHRP, once the NBMA next hop has been resolved, the source may 80 either start sending IP packets to the destination (in a 81 connectionless NBMA network such as SMDS) or may first establish a 82 connection to the destination with the desired bandwidth and QOS 83 characteristics (in a connection-oriented NBMA network such as ATM). 85 NHRP in its most basic form provides a simple IP-to-NBMA-address 86 binding service. This may be sufficient for hosts which are directly 87 connected to an NBMA network, allowing for straightforward 88 implementations in NBMA stations. Optional services extend this 89 functionality to include loop detection, sanity checks, diagnostics, 90 security features, and fallback capabilities, providing improved 91 robustness and functionality. 93 NHRP supports both a server-based style of deployment and a 94 ubiquitous "fabric", consisting of NHRP-capable routers. The 95 server-based approach requires a smaller number of machines (possibly 96 one) to support NHRP, but requires significantly more manual 97 configuration. 99 Address resolution techniques such as those described in [3] and [4] 100 may be in use when NHRP is deployed. ARP servers and services over 101 NBMA networks may be required to support hosts that are not capable 102 of dealing with any model for communication other than the LIS model, 103 and deployed hosts may not implement NHRP but may continue to support 104 ARP variants such as those described in [3] and [4]. NHRP is 105 designed to eliminate the suboptimal routing that results from the 106 LIS model, and can be deployed in a non-interfering manner alongside 107 existing ARP services. 109 2. Protocol Overview 111 In this section, we briefly describe how a source S (which 112 potentially can be either a router or a host) uses NHRP to determine 113 the "NBMA next hop" to destination D. 115 For administrative and policy reasons, a physical NBMA network may be 116 partitioned into several, disjoint "Logical NBMA networks". A 117 Logical NBMA network is defined as a collection of hosts and routers 118 that share ulfiltered data link connectivity over an NBMA network. 119 "Unfiltered data link connectivity" refers to the absence of closed 120 user groups, address screening or similar features that may be used 121 to prevent direct communication between stations connected to the 122 same NBMA network. (Hereafter, unless otherwise specified, we use 123 NBMA network to mean logical NBMA network.) 125 Placed within the NBMA network are one or more entities that 126 implement the NHRP protocol, otherwise known as "Next Hop Servers" 127 (NHSs). Each NHS serves a set of destination hosts, which may or may 128 not be directly connected to the NBMA network. NHSs cooperatively 129 resolve the NBMA next hop within their logical NBMA network. In 130 addition to the NHRP, NHSs participate in protocols used to 131 disseminate routing information across (and beyond the boundaries of) 132 the NBMA network, and may support "classical" ARP service as well. 134 An NHS maintains a "next-hop resolution" cache, which is a table of 135 address mappings (IP-to-NBMA address). This table can be constructed 136 from information gleaned from NHRP Register packets (see Section 137 5.4), extracted from NHRP requests or replies that traverse the NHS 138 as they are forwarded, or through mechanisms outside the scope of 139 this document (examples of such mechanisms include ARP [2, 3, 4] and 140 pre-configured tables). 142 A host or router that is not an NHRP speaker must be configured with 143 the identity of the NHS which serves it (see Configuration, Section 144 4). 146 [Note: for NBMA networks that offer group or multicast addressing 147 features, it may be desirable to configure stations with a group 148 identity for NHSs, i.e., addressing information that would solicit a 149 response from "all NHSs". The means whereby a group of NHSs divide 150 responsibilities for next hop resolution are not described here.] 152 The protocol proceeds as follows. An event occurs triggering station 153 S to want to resolve the NBMA address of a path to D. This is most 154 likely to be when a data packet addressed to station D is to be 155 emitted from station S (either because station S is a host, or 156 station S is a transit router), but could also be triggered by other 157 means (a resource reservation request, for example). Station S first 158 determines the next hop to station D through normal routing processes 159 (for a host, the next hop may simply be the default router; for 160 routers, this is the "next hop" to the destination IP address). If 161 the next hop is reachable through its NBMA interface, S constructs an 162 NHRP request packet (see Section 5.2) containing station D's IP 163 address as the (target) destination address, S's own IP address as 164 the source address (NHRP request initiator), and station S's NBMA 165 addressing information. Station S may also indicate that it prefers 166 an authoritative reply (i.e., station S only wishes to receive a 167 reply from the NHS-speaker that maintains the NBMA-to-IP address 168 mapping for this destination). Station S encapsulates the NHRP 169 request packet in an IP packet containing as its destination address 170 the IP address of its NHS. This IP packet is emitted across the NBMA 171 interface to the NBMA address of the NHS. 173 If the NHRP request is triggered by a data packet, station S may 174 choose to dispose of the data packet while awaiting an NHRP reply in 175 one of the following ways: 177 (a) Drop the packet 178 (b) Retain the packet until the reply arrives and a more optimal 179 path is available 180 (c) Forward the packet along the routed path toward D 182 The choice of which of the above to perform is a local policy matter, 183 though option (c) is the recommended default, since it may allow data 184 to flow to the destination while the NBMA address is being resolved. 186 When the NHS receives an NHRP request, it checks to see if it 187 "serves" station D, i.e., the NHS checks to see if it has a "next 188 hop" entry for D in its next-hop resolution cache. If the NHS does 189 not serve D, the NHS forwards the NHRP request to another NHS. 191 (Mechanisms for determining how to forward the NHRP request are 192 discussed in Section 3, Modes of Deployment.) 194 If this NHS serves D, the NHS resolves station D's NBMA address, and 195 generates a positive NHRP reply on D's behalf. (NHRP replies in this 196 scenario are always marked as "authoritative".) The NHRP reply 197 packet contains the next hop IP and NBMA address for station D and is 198 sent back to S. (Note that if station D is not on the NBMA network, 199 the next hop IP address will be that of the egress router through 200 which packets for station D are forwarded.) 202 NHRP replies usually traverse the same sequence of NHSs as the NHRP 203 request (in reverse order). This is a consequence of having 204 symmetric routing, which is typically (but not necessarily) the case. 205 An NHS receiving an NHRP reply may cache the NBMA next hop 206 information contained therein. To a subsequent NHRP request, this 207 NHS may respond with the cached, non-authoritative, NBMA next hop 208 information or with cached negative information. Non-authoritative 209 NHRP replies are distinguished from authoritative replies so that if 210 a communication attempt based on non-authoritative information fails, 211 a source station can choose to send an authoritative NHRP request. 212 NHSs MUST never respond to authoritative NHRP requests with cached 213 information. 215 [Note: An NHRP reply can be returned directly to the NHRP request 216 initiator, i.e., without traversing the list of NHSs that forwarded 217 the request, if all of the following criteria are satisfied: 219 (a) Direct communication is available via datagram transfer 220 (e.g., SMDS) or the NHS has an existing virtual circuit 221 connection to the NHRP request initiator or is permitted 222 to open one. 223 (b) The NHRP request initiator has not included the NHRP 224 Reverse NHS record Option (see Section 5.6.5). 225 (c) The NHRP request initiator has not included the destination 226 mask option (see Section 5.6.1). 227 (d) The authentication policy in force permits direct 228 communication between the NHS and the NHRP request 229 initiator. 231 The purpose of allowing an NHS to reply directly is to reduce 232 response time. A consequence of allowing a direct reply is that 233 NHSs that would under normal circumstances be traversed by the 234 reply would not cache next hop information contained therein.] 236 The process of forwarding the NHRP request is repeated until the 237 request is satisfied, or an error occurs (e.g., no NHS in the NBMA 238 network can resolve the request.) If the determination is made that 239 station D's next hop cannot be resolved, a negative reply is 240 returned. This occurs when (a) no next-hop resolution information is 241 available for station D from any NHS, or (b) an NHS is unable to 242 forward the NHRP request (e.g., connectivity is lost). 244 NHRP requests and replies MUST never cross the borders of a logical 245 NBMA network (an explicit NBMA network identifier may be included as 246 an option in the NHRP request, see section 5.6.2). Thus, IP traffic 247 out of and into a logical NBMA network always traverses an IP router 248 at its border. Network layer filtering can then be implemented at 249 these border routers. 251 NHRP optionally provides a mechanism to aggregate NBMA next hop 252 information in NHS caches. Suppose that router X is the NBMA next 253 hop from station S to station D. Suppose further that X is an egress 254 router for all stations sharing an IP address prefix with station D. 255 When an NHRP reply is generated in response to a request, the 256 responder may augment the IP address of station D with a mask 257 defining this prefix (see Section 5.6.1). The prefix to egress 258 router mapping in the reply MUST be cached in all NHSs on the path of 259 the reply. A subsequent (non-authoritative) NHRP request for some 260 destination that shares an IP address prefix with D can be satisfied 261 with this cached information. 263 To dynamically detect link-layer filtering in NBMA networks (e.g., 264 X.25 closed user group facility, or SMDS address screens), as well as 265 to provide loop detection and diagnostic capabilities, NHRP 266 optionally incorporates a "Route Record" in requests and replies (see 267 Sections 5.6.4 and 5.6.5). The Route Record options contain the 268 network (and link layer) addresses of all intermediate NHSs between 269 source and destination (in the forward direction) and between 270 destination and source (in the reverse direction). When a source 271 station is unable to communicate with the responder, it may attempt 272 to do so successively with other link layer addresses in the Route 273 Record until it succeeds (if authentication policy permits such 274 action). This approach can find the optimal best hop in the presence 275 of link-layer filtering (which may be source/destination sensitive, 276 for instance, without necessarily creating separate logical NBMA 277 networks) or link-layer congestion (especially in connection-oriented 278 media). 280 3. Modes of Deployment 282 NHRP supports two deployment modes of operation: "server" and 283 "fabric" modes. The two modes differ only in the way NHRP packets 284 are propagated, which is driven by differences in configuration. 286 It is desirable that hosts attached directly to the NBMA network have 287 no knowledge of whether NHRP is deployed in "server" or "fabric" 288 modes, so that a change in deployment strategy can be done within a 289 single administration, transparently to hosts. For this reason, host 290 configuration is invariant between the two cases. Note that 291 irrespective of which mode is deployed, NHRP clients must nominally 292 be configured with the NBMA (and IP) address of at least one NHS. In 293 practice, a host's default router should also be its NHS. 295 Server Mode 297 In "server" mode, the expectation is that a small number of NHSs 298 will be fielded in an NBMA network. This may be appropriate in 299 networks containing routers that do not support NHRP, or networks 300 that have large numbers of directly-attached hosts (and relatively 301 few routers). Server mode assumes that NHRP is very loosely 302 coupled with IP routing, and that the path taken by NHRP requests 303 has little to do with the path taken by IP data packets routed to 304 the desired destination. 306 [Note: This is the likely scenario for initial deployment of NHRP. 307 It is also likely that single and Multi-LIS configurations using 308 either group-addressed ARP (in the case of SMDS) or ARP servers (in 309 the case of ATM or SMDS) may already be in place.] 311 Server mode uses static configuration of NHS identity. The client 312 station must be configured with the IP address of one or more NHSs, 313 and there must be a path to that NHS (either directly, in which 314 case the NHS's NBMA address must be known, or indirectly, through a 315 router whose NBMA address is known). If there are multiple NHSs, 316 they must be configured with each others' addresses, the identities 317 of the destinations that each of them serves, and optionally a 318 logical NBMA network identifier. (This static configuration 319 requirement, which may involve authentication as well as addressing 320 information, tends to limit such deployments to a very small number 321 of NHSs.) 323 If the NBMA network offers a group addressing or multicast feature, 324 the client (station) may be configured with a group address 325 assigned to the group of next-hop servers. The client might then 326 submit NHRP requests to the group address, eliciting a response 327 from one or more NHSs, depending on the response strategy selected. 328 Note that the constraints described in Section 2 regarding direct 329 replies may apply. 331 The servers can also be deployed with the group or multicast 332 address of their peers, and an NHS might use this as a means of 333 forwarding NHRP requests it cannot satisfy to its peers. This 334 might elicit a response (to the NHS) from one or more NHSs, 335 depending on the response strategy. The NHS would then forward the 336 NHRP reply to the NRHP request originator. The purpose of using 337 group addressing or a similar multicast mechanism in this scenario 338 would be to eliminate the need to preconfigure each NHS in a 339 logical NBMA network with both the individual identities of other 340 NHSs as well as the destinations they serve. It reduces the number 341 of NHSs that might be traversed to process an NHRP request (in 342 those configurations where NHSs either respond or forward via the 343 multicast, only two NHSs would be traversed), and allows the NHS 344 that serves the NHRP request originator to cache next hop 345 information associated with the reply (again, within the 346 constraints described in Section 2). 348 The NHRP request packet's destination IP address is set by the 349 source station to the first-hop NHS's IP address. If the addressed 350 NHS does not serve the destination, the NHRP request is forwarded 351 to the IP address of the NHS that serves the destination. 353 The responding NHS uses the source address from within the NHRP 354 packet (not the source address of the IP packet) as the IP 355 destination of the NHRP reply. 357 Fabric Mode 359 In "fabric" mode, it is expected that NHRP-capable routers are 360 ubiquitous throughout the NBMA network, and that NHSs acquire 361 knowledge about destinations other NHSs serve as a direct 362 consequence of participating in intradomain and interdomain routing 363 protocol exchange. In particular, it is expected that an NHS 364 serving a particular destination is guaranteed to lie along the 365 routed path to that destination. In practice, this means that all 366 egress routers must double as NHSs serving the destinations beyond 367 them, and that hosts on the NBMA network are served by routers that 368 double as NHSs. 370 Fabric mode leverages a routed infrastructure that "overlays" the 371 NBMA network. The source station passes the NHRP request to the 372 router which serves as the next hop toward the destination. Each 373 router in turn forwards the NHRP request toward the destination. 374 Eventually, the NHRP request arrives at a router that is acting as 375 an NHS serving the destination (or the destination itself, if it is 376 an NHRP-speaker), which generates the NHRP reply. 378 If the source station is a host, it sets the IP destination address 379 of the NHRP request to the first-hop NHS/router (so that hosts 380 needn't know the mode in which the network is running). If the 381 source station is a router, the destination IP address may be set 382 either to the next-hop router or to the ultimate destination being 383 resolved. Each NHS/router examines the NHRP request packet on its 384 way toward the destination, optionally modifying it on the way 385 (such as updating the Forward Record option). The Router Alert 386 option [6] is added by the first NHS in order to ensure that 387 router/NHSs along the path process the packet, even though it may 388 be addressed to the ultimate destination. 390 If an NHS/router receives an NHRP packet addressed to itself to 391 which it cannot reply (because it does not serve the destination 392 directly), it will forward the NHRP request with the destination IP 393 address set to the ultimate destination (thus allowing invariant 394 host behavior). Eventually, the NHRP packet will arrive at the 395 router/NHS that serves the destination (which will return a 396 positive NHRP reply) or it will arrive at a router/NHS that has no 397 route to the destination (which will return a negative NHRP reply), 398 or it may arrive at a router/NHS that cannot reach the NHS that 399 serves the destination due to a loss of reachability among the NHSs 400 (in which case the router will return a negative NHRP reply). 402 The procedural difference between server mode and fabric mode is 403 reduced to deciding how to update the destination address in the IP 404 packet carrying the NHRP request. 406 Note that addressing the NHRP request to the ultimate destination 407 allows for networks that do not have NHSs deployed in all routers; 408 typically a very large NBMA network might only deploy NHSs in 409 egress routers, and not in transit routers. 411 4. Configuration 413 Stations 415 To participate in NHRP, a station connected to an NBMA network 416 should be configured with the IP and NBMA address(es) of its NHS(s) 417 (alternatively, it should be configured with a means of acquiring 418 them, i.e., the group address that members of a NHS group use for 419 the purpose of address or next-hop resolution.) The NHS(s) may be 420 physically located on the stations's default or peer routers, so 421 their addresses may be obtained from the station's IP forwarding 422 table. If the station is attached to several link layer networks 423 (including logical NBMA networks), the station should also be 424 configured to receive routing information from its NHS(s) and peer 425 routers so that it can determine which IP networks are reachable 426 through which link layer networks. 428 Next Hop Servers 430 An NHS is configured with its own identity, a set of IP address 431 prefixes that correspond to the IP addresses of the stations it 432 serves, a logical NBMA network identifier (see Section 5.6.2), and 433 in the case of "server" mode, the identities of other NHSs in the 434 same logical NBMA network. If a served station is attached to 435 several link layer networks, the NHS may also need to be configured 436 to advertise routing information to such stations. 438 If an NHS acts as an egress router for stations connected to other 439 link layer networks than the NBMA network, the NHS must, in 440 addition to the above, be configured to exchange routing 441 information between the NBMA network and these other link layer 442 networks. 444 In all cases, routing information is exchanged using conventional 445 intra-domain and/or inter-domain routing protocols. 447 The NBMA addresses of the stations served by the NHS may be learned 448 via NHRP Register packets or manual configuration. 450 5. Packet Formats 452 This section describes the format of NHRP packets. 454 An NHRP packet consists of a Fixed Part, a Mandatory Part, and an 455 Options Part. The Fixed Part is common to all NHRP packet types. 456 The Mandatory Part must be present, but varies depending on packet 457 type. The Options Part also varies depending on packet type, and 458 need not be present. 460 The length of the Fixed Part is fixed at 8 octets. The length of the 461 Mandatory Part is carried in the Fixed Part. The length of the 462 Options Part is implied by the total packet length (Internet datagram 463 total length minus IP header length minus NHRP fixed part length 464 minus NHRP mandatory part length). 466 Note that since the lengths of all fields are self-encoding, it is 467 permissible to pad the Mandatory and Options parts with arbitrary 468 numbers of trailing zero octets to achieve any desired alignment. 469 Note however that any padding in the Mandatory Part must be included 470 in the Mandatory Part Length. 472 NHRP packets are carried in IP packets as protocol type 54 (decimal). 473 NHSs may increase the size of an NHRP packet as a result of option 474 processing. IP datagrams containing NHRP packets must have the Don't 475 Fragment bit set. 477 Fields marked "unused" must be set to zero on transmission, and 478 ignored on receipt. 480 Most packet types have both network layer protocol-independent fields 481 and protocol-specific fields. The protocol-independent fields always 482 come first in the packet, and the Protocol ID field qualifies the 483 format of the protocol-specific fields. The protocol-specific fields 484 defined in this document are for IPv4 only; formats of protocol- 485 specific fields for other protocols are for further study. 487 5.1 NHRP Fixed Header 489 The NHRP Fixed Header is present in all NHRP packets. It contains 490 the basic information needed to parse the rest of the packet. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Version | Hop Count | Checksum | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Unused | Mandatory Part Length | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Version 501 The NHRP version number. Currently this value is 1. 503 Hop Count 504 The Hop count indicates the maximum number of NHSs that an NHRP 505 packet is allowed to traverse before being discarded. 507 Checksum 508 The standard IP checksum over the entire NHRP packet (starting with 509 the fixed header). If only the hop count field is changed, the 510 checksum is adjusted without full recomputation. The checksum is 511 completely recomputed when other header fields are changed. 513 Type 514 The NHRP packet type: Request, Response, Register, or Error 515 Indication (see below). 517 Mandatory Part Length 518 The length in octets of the Mandatory Part. This length does not 519 include the Fixed Header. 521 5.2 NHRP Request 523 The NHRP Request packet has a Type code of 1. The Mandatory Part has 524 the following format: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |Q|S|A|P| Unused | Protocol ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Request ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 (IPv4-Specific) 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Destination IP address | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Source IP address | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Holding Time | Address Type | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Unused | NBMA Length | NBMA Address (variable length)| 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Q 546 Set if the Requestor is a router; clear if the requestor is a 547 host. 549 S 550 Unused (zero on transmit) 552 A 553 A response to an NHRP request may contain cached information. If 554 an authoritative answer is desired, then this bit ("Authoritative") 555 should be set. If non-authoritative (cached) information is 556 acceptable, this bit should be clear. 558 P 559 Unused (zero on transmit) 561 Protocol ID 562 Specifies the network layer protocol for which we are obtaining 563 routing information. This value also qualifies the structure of 564 the remainder of the Mandatory Part. For IPv4, the Protocol ID is 565 hexadecimal 800 (decimal 2048). Protocol ID values for other 566 network layer protocols are for future study. 568 Request ID 569 A value chosen by the source to aid in matching requests with 570 replies. This value could also be sent across a virtual circuit 571 (in SVC environments) to aid in matching NHRP transactions with 572 virtual circuits (this use is for further study). 574 Destination and Source IP Addresses 575 Respectively, these are the IP addresses of the station for which 576 the NBMA next hop is desired, and the NHRP request initiator. 578 Source Holding Time, Address Type, NBMA Length, and NBMA Address 579 The Holding Time field specifies the number of seconds for which 580 the source NBMA information is considered to be valid. Cached 581 information shall be discarded when the holding time expires. 583 The Address Type field specifies the type of NBMA address 584 (qualifying the NBMA address). Possible address types are listed 585 in [5]. 587 The NBMA length field is the length of the NBMA address of the 588 source station in bits. The NBMA address field itself is zero- 589 filled to the nearest 32-bit boundary. 591 5.3 NHRP Reply 593 The NHRP Reply packet has a type code of 2. The Mandatory Part has 594 the following format: 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |Q|S|A|P| Unused | Protocol ID | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Request ID | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 (IPv4-Specific) 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Destination IP address | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Source IP address | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Next-hop IP address | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Holding Time | Address Type | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Preference | NBMA Length | NBMA Address (variable length)| 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 ... 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Next-hop IP address | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Holding Time | Address Type | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Preference | NBMA Length | NBMA Address (variable length)| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Q 628 Copied from the NHRP Request. Set if the Requestor is a router; 629 clear if the requestor is a host. 631 S 632 Set if the next hop identified in the reply is a router; clear if 633 the next hop is a host. 635 A 636 Set if the reply is authoritative; clear if the reply is non- 637 authoritative. 639 P 640 Set if the reply is positive; clear if the reply is negative. 642 An NHS is not allowed to reply to an NHRP request for authoritative 643 information with cached information, but may do so for an NHRP 644 Request which indicates a request for non-authoritative information. 645 An NHS may reply to an NHRP request for non-authoritative information 646 with authoritative information. 648 Protocol ID 649 Specifies the network layer protocol for which we are obtaining 650 routing information. This value also qualifies the structure of 651 the remainder of the Mandatory Part. For IPv4, the Protocol ID is 652 hexadecimal 800 (decimal 2048). Protocol ID values for other 653 network layer protocols are for future study. 655 Request ID 656 Copied from the NHRP Request. 658 Destination IP Address 659 The address of the target station (copied from the corresponding 660 NHRP Request). 662 Source IP Address 663 The address of the initiator of the request (copied from the 664 corresponding NHRP Request). 666 Next-hop entry 667 A Next-hop entry consists of the following fields: a 32-bit Next- 668 hop IP Address, a 16-bit Holding Time, an 8-bit Preference, an 8- 669 bit Address Type, an 8-bit NBMA Length, and an NBMA Address whose 670 length is the value of the NBMA length field. 672 The Next-hop IP Address specifies the IP address of the next hop. 673 This will be the address of the destination host if it is directly 674 attached to the NBMA network, or the egress router if it is not 675 directly attached. 677 The Holding Time field specifies the number of seconds for which 678 the associated Next-hop entry information is considered to be 679 valid. Cached information shall be discarded when the holding time 680 expires. (Holding time is to be specified for both positive and 681 negative replies). 683 The Address Type field specifies the type of NBMA address 684 (qualifying the NBMA address). Possible address types are listed 685 in [5]. 687 The Preference field specifies the preference of the Next-hop 688 entry, relative to other Next-hop entries in this NHRP Reply 689 packet. Higher values indicate more preferable Next-hop entries. 690 Action taken when multiple next-hop entries have the highest 691 preference value is a local matter. 693 The NBMA length field specifies the length of the NBMA address of 694 the destination station in bits. The NBMA address field itself is 695 zero-filled to the nearest 32-bit boundary. For negative replies, 696 the Holding Time field is relevant; however, the preference, 697 Address Type, and NBMA length fields must be zero, and the NBMA 698 Address shall not be present. 700 There may be multiple Next-hop entries returned in the reply (as 701 implied by the Mandatory Part Length). The preference values are 702 used to select the preferred entry. The same next-hop IP address 703 may be associated with multiple NBMA addresses. Load-splitting may 704 be performed over the addresses, given equal preference values, and 705 the alternative addresses may be used in case of connectivity 706 failure in the NBMA network (such as a failed call attempt in 707 connection-oriented NBMA networks). 709 5.4 NHRP Register 711 The NHRP Register packet is sent from a station to an NHS to notify 712 the NHS of the station's NBMA address. It has a Type code of 3. The 713 Mandatory Part has the following format: 715 0 1 2 3 716 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 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | Unused | Protocol ID | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 (IPv4-Specific) 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Source IP address | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Holding Time | Address Type | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Unused | NBMA Length | NBMA Address (variable length)| 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Protocol ID 731 Specifies the network layer protocol for which we are obtaining 732 routing information. This value also qualifies the structure of 733 the remainder of the Mandatory Part. For IPv4, the Protocol ID is 734 hexadecimal 800 (decimal 2048). Protocol ID values for other 735 network layer protocols are for future study. 737 Source IP Address 738 The IP address of the station wishing to register its NBMA address 739 with an NHS. 741 Source Holding Time, Address Type, NBMA Length, and NBMA Address 742 The Holding Time field specifies the number of seconds for which 743 the source NBMA information is considered to be valid. Cached 744 information shall be discarded when the holding time expires. 746 The Address Type field specifies the type of NBMA address 747 (qualifying the NBMA address). Possible address types are listed 748 in [5]. 750 The NBMA length field is the length of the NBMA address of the 751 source station in bits. The NBMA address itself is zero-filled to 752 the nearest 32-bit boundary. 754 This packet is used to register a station's IP and NBMA addresses 755 with its configured NHS. This allows static configuration 756 information to be reduced; the NHSs need not be configured with the 757 identities of all of the stations that they serve. 759 It is possible that a misconfigured station will attempt to register 760 with the wrong NHS (i.e., one that cannot serve it due to policy 761 constraints or routing state). If this is the case, the NHS must 762 reply with an Error Indication of type Can't Serve This Address. 764 If an NHS cannot serve a station due to a lack of resources, the NHS 765 must reply with an Error Indication of type Registration Overflow. 767 In order to keep the registration entry from being discarded, the 768 station must resend the Register packet often enough to refresh the 769 registration, even in the face of occasional packet loss. It is 770 recommended that the Registration packet be sent at an interval equal 771 to one-third of the Holding Time specified therein. 773 5.5 NHRP Error Indication 775 The NHRP Error Indication is used to convey error indications to the 776 initiator of an NHRP Request packet. It has a type code of 4. The 777 Mandatory Part has the following format: 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Error Code | Error Offset | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 +-+-+-+-+-+-+-+ Contents of NHRP Packet in error +-+-+-+-+-+-+-+ 786 | | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Error Code 790 An error code indicating the type of error detected, chosen from 791 the following list: 793 1 - Unrecognized Option 794 2 - Network ID Mismatch 795 3 - NHRP Loop Detected 796 4 - Can't Serve This Address 797 5 - Registration Overflow 798 6 - Server Unreachable 799 7 - Protocol Error 800 8 - NHRP fragmentation failure 802 Error Offset 803 The offset in octets into the original NHRP packet, starting at the 804 NHRP Fixed Header, at which the error was detected. 806 The destination IP address of an NHRP Error Indication shall be set 807 to the IP address of the initiator of the original NHRP Request (as 808 extracted from the NHRP Request or NHRP Reply). 810 An Error Indication packet shall never be generated in response to 811 another Error Indication packet. When an Error Indication packet is 812 generated, the offending NHRP packet shall be discarded. In no case 813 should more than one Error Indication packet be generated for a 814 single NHRP packet. 816 5.6 Options Part 818 The Options Part, if present, carries one or more options in {Type, 819 Length, Value} triplets. Options are only present in a Reply if they 820 were present in the corresponding Request; therefore, minimal NHRP 821 station implementations that do not act as an NHS and do not transmit 822 options need not be able to receive them. An implementation that is 823 incapable of processing options shall return an Error Indication of 824 type Unrecognized Option when it receives an NHRP packet containing 825 options. 827 Options are typically protocol-specific, as noted. 829 Options have the following format: 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |O| Type | Length | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Value... | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 O 840 "Optional." If set, and the NHS does not recognize the type code, 841 the option may safely be ignored. If clear, and the NHS does not 842 recognize the type code, the NHRP request is considered in error. 843 (See below for details.) 845 Type 846 The option type code (see below). The option type is not qualified 847 by the Optional bit, but is orthogonal to it. 849 Length 850 The length in octets of the value (not including the Type and 851 Length fields; a null option will have only an option header and a 852 length of zero). 854 Each option is padded with zero octets to a 32 bit boundary. This 855 padding is not included in the Length field. 857 Options may occur in any order, but any particular option type may 858 occur only once in an NHRP packet. 860 The Optional bit provides for a means to extend the option set. If 861 it is clear, the NHRP request cannot be satisfied if the option is 862 unrecognized, so the responder must return an Error Indication of 863 type Unrecognized Option. If set, the option can be safely ignored. 864 In this case, the offending option should simply be returned 865 unchanged in the NHRP Reply. 867 If a transit NHS (one which is not going to generate a reply) detects 868 an unrecognized option, it shall ignore the option, and if the 869 Optional bit is clear, must not cache the information (in the case of 870 a reply) and must not identify itself as an egress router (in the 871 Forward Record or Reverse Record options). Effectively, this means 872 that a transit NHS that doesn't understand an option with the 873 Optional bit clear must not participate in any way in the protocol 874 exchange, other than acting as a forwarding agent for the request. 876 5.6.1 Destination Mask Option (IPv4-Specific) 878 Optional = 0 879 Type = 1 880 Length = 4 882 This option is used to indicate that the information carried in an 883 NHRP Reply pertains to an equivalence class of destinations rather 884 than just the destination IP address specified in the request. All 885 addresses that match the destination IP address in the bit positions 886 for which the mask has a one bit are part of the equivalence class. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Destination Mask | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 If an initiator would like to receive this equivalence information, 895 it shall add this option to the NHRP Request with a value of 896 255.255.255.255. The responder shall copy the option to the NHRP 897 Reply and modify the mask appropriately. 899 5.6.2 NBMA Network ID Option (Protocol-Independent) 901 Optional = 0 902 Type = 2 903 Length = variable 905 This option is used to carry one or more identifiers for the NBMA 906 network. This can be used as a validity check to ensure that the 907 request does not leave a particular NBMA network. The option is 908 placed in an NHRP Request packet by the initiator with an ID value of 909 zero; the first NHS fills in the field with the identifier(s) for 910 the NBMA network. 912 Multiple NBMA Network IDs may be used as a transition mechanism while 913 NBMA Networks are being split or merged. 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | NBMA Network ID | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 ... 922 Each identifier consists of a 32 bit globally unique value assigned 923 to the NBMA network. This value should be chosen from the IP address 924 space administered by the operators of the NBMA network. This value 925 is used for identification only, not for routing or any other 926 purpose. 928 Each NHS processing an NHRP Request shall verify these values. If 929 none of the values matches the NHS's NBMA Network ID, the NHS shall 930 return an Error Indication of type "Network ID Mismatch" and discard 931 the NHRP Request. 933 When an NHS is building an NHRP Reply and the NBMA Network ID option 934 is present in the NHRP Request, the NBMA Network ID option shall be 935 copied from the Request to the Reply, including all values carried 936 therein. 938 Each NHS processing an NHRP Reply shall verify the values carried in 939 the NBMA Network ID option, if present. If none of the values 940 matches the NHSs NBMA Network ID, the NHS shall return an Error 941 Indication of type "Network ID Mismatch" and discard the NHRP Reply. 943 5.6.3 Responder Address Option (IPv4-Specific) 945 Optional = 0 946 Type = 3 947 Length = 4 949 This option is used to determine the IP address of the NHRP 950 Responder, that is, the entity that generates the NHRP Reply packet. 951 The intent is to identify the entity responding to the request, which 952 may be different (in the case of cached replies) than the system 953 identified in the Next-hop field of the reply, and to aid in 954 detecting loops in the NHRP forwarding path. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Responder's IP Address | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 If a requestor desires this information, it shall include this 963 option, with a value of zero, in the NHRP Request packet. 965 If an NHS is generating an NHRP Reply packet in response to a request 966 containing this option, it shall include this option, containing its 967 IP address, in the NHRP Reply. If an NHS has more than one IP 968 address, it shall use the same IP address consistently in all of the 969 Responder Address, Forward NHS Record, and Reverse NHS Record 970 options. The choice of which of several IP addresses to include in 971 this option is a local matter. 973 If an NHRP Reply packet being forwarded by an NHS contains an IP 974 address of that NHS in the Responder Address Option, the NHS shall 975 generate an Error Indication of type "NHRP Loop Detected" and discard 976 the Reply. 978 If an NHRP Reply packet is being returned by an intermediate NHS 979 based on cached data, it shall place its own address in this option 980 (differentiating it from the address in the Next-hop field). 982 5.6.4 NHRP Forward NHS Record Option (IPv4-Specific) 984 Optional = 0 985 Type = 4 986 Length = variable 988 The NHRP forward NHS record is a list of NHSs through which an NHRP 989 request traverses. Each NHS shall append a Next-hop element 990 containing its IP address to this option. 992 In addition, NHSs that are willing to act as egress routers for 993 packets from the source to the destination shall include information 994 about their NBMA Address. 996 Each Next-hop element is formatted as follows: 998 0 1 2 3 999 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 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | IP address | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Holding Time | Address Type | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Unused | NBMA Length | NBMA Address (variable length)| 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 IP address 1009 The IP address of the NHS. 1011 Holding Time 1012 The number of seconds for which this information is valid. If a 1013 station chooses to use this information as a next-hop entry, it may 1014 not be used once the holding timer expires. 1016 Address Type, NBMA Length, and NBMA Address 1017 The Address Type field specifies the type of NBMA address 1018 (qualifying the NBMA address). Possible address types are listed 1019 in [5]. 1021 The NBMA length field is the length of the NBMA address of the 1022 destination station in bits. The NBMA address itself is zero- 1023 filled to the nearest 32-bit boundary. 1025 NHSs that are not egress routers shall specify an NBMA Length of 1026 zero and shall not include an NBMA Address. 1028 If a requestor wishes to obtain this information, it shall include 1029 this option with a length of zero. 1031 Each NHS shall append an appropriate Next-hop element to this option 1032 when processing an NHRP Request. The option length field and NHRP 1033 checksum shall be adjusted as necessary. 1035 The last-hop NHS (the one that will be generating the NHRP Reply) 1036 shall not update this option (since this information will be in the 1037 reply). 1039 If an NHS has more than one IP address, it shall use the same IP 1040 address consistently in all of the Responder Address, Forward NHS 1041 Record, and Reverse NHS Record options. The choice of which of 1042 several IP addresses to include in this option is a local matter. 1044 If an NHRP Request packet being forwarded by an NHS contains the IP 1045 address of that NHS in the Forward NHS Record Option, the NHS shall 1046 generate an Error Indication of type "NHRP Loop Detected" and discard 1047 the Request. 1049 5.6.5 NHRP Reverse NHS Record Option (IPv4-Specific) 1051 Optional = 0 1052 Type = 5 1053 Length = variable 1055 The NHRP reverse NHS record is a list of NHSs through which an NHRP 1056 reply traverses. Each NHS shall append a Next-hop element containing 1057 its IP address to this option. 1059 In addition, NHSs that are willing to act as egress routers for 1060 packets from the source to the destination shall include information 1061 about their NBMA Address. 1063 Each Next-hop element is formatted as follows: 1065 0 1 2 3 1066 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 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | IP address | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Holding Time | Address Type | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | Unused | NBMA Length | NBMA Address (variable length)| 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 IP address 1076 The IP address of the NHS. 1078 Holding Time 1079 The number of seconds for which this information is valid. If a 1080 station chooses to use this information as a next-hop entry, it may 1081 not be used once the holding timer expires. 1083 Address Type, NBMA Length, and NBMA Address 1084 The Address Type field specifies the type of NBMA address 1085 (qualifying the NBMA address). Possible address types are listed 1086 in [5]. 1088 The NBMA length field is the length of the NBMA address of the 1089 destination station in bits. The NBMA address itself is zero- 1090 filled to the nearest 32-bit boundary. 1092 NHSs that are not egress routers shall specify an NBMA Length of 1093 zero and shall not include an NBMA Address. 1095 If a requestor wishes to obtain this information, it shall include 1096 this option with a length of zero. 1098 Each NHS shall append an appropriate Next-hop element to this option 1099 when processing an NHRP Reply. The option length field and NHRP 1100 checksum shall be adjusted as necessary. 1102 The NHS generating the NHRP Reply shall not update this option. 1104 If an NHS has more than one IP address, it shall use the same IP 1105 address consistently in all of the Responder Address, Forward NHS 1106 Record, and Reverse NHS Record options. The choice of which of 1107 several IP addresses to include in this option is a local matter. 1109 If an NHRP Reply packet being forwarded by an NHS contains the IP 1110 address of that NHS in the Reverse NHS Record Option, the NHS shall 1111 generate an Error Indication of type "NHRP Loop Detected" and discard 1112 the Reply. 1114 Note that this information may be cached at intermediate NHSs; if 1115 so, the cached value shall be used when generating a reply. Note 1116 that the Responder Address option may be used to disambiguate the set 1117 of NHSs that actually processed the reply. 1119 5.6.6 NHRP QoS Option 1121 Optional = 0 1122 Type = 6 1123 Length = variable 1125 The NHRP QoS Option is carried in NHRP Request packets to indicate 1126 the desired QoS of the path to the indicated destination. This 1127 information may be used to help select the appropriate NBMA next hop. 1129 It may also be carried in NHRP Register packets to indicate the QoS 1130 to which the registration applies. 1132 The syntax and semantics of this option are TBD; alignment with 1133 resource reservation may be useful. 1135 5.6.7 NHRP Authentication Option 1137 Optional = 0 1138 Type = 7 1139 Length = variable 1141 The NHRP Authentication Option is carried in NHRP packets to convey 1142 authentication information between NHRP speakers. The Authentication 1143 Option may be included in any NHRP packet type. 1145 Authentication is done pairwise on an NHRP hop-by-hop basis; the 1146 authentication option is regenerated on each hop. If a received 1147 packet fails the authentication test, the NHS shall generate an Error 1148 Indication of type "Authentication Failure" and discard the packet. 1149 In no case shall an Error Indication packet be generated on the 1150 receipt of an Error Indication packet, however. Note that one 1151 possible authentication failure is the lack of an Authentication 1152 Option; the presence or absence of the Authentication Option is a 1153 local matter. 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Authentication Type | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | | 1161 +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+ 1162 | | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 The Authentication Type field identifies the authentication method in 1166 use. Currently assigned values are: 1168 1 - Cleartext Password 1169 2 - Keyed MD5 1171 All other values are reserved. 1173 The Authentication Data field contains the type-specific 1174 authentication information. 1176 In the case of Cleartext Password Authentication, the Authentication 1177 Data consists of a variable length password. 1179 In the case of Keyed MD5 Authentication, the Authentication Data 1180 contains the 16 byte MD5 digest of the entire NHRP packet, including 1181 the IP header, with the authentication key appended to the end of the 1182 packet. The authentication key is not transmitted with the packet. 1184 Distribution of authentication keys is outside the scope of this 1185 document. 1187 5.6.8 NHRP Vendor-Private Option 1189 Optional = 0 1190 Type = 8 1191 Length = variable 1193 The NHRP Vendor-Private Option is carried in NHRP packets to convey 1194 vendor-private information or NHRP extensions between NHRP speakers. 1195 This option may be used at any time; if the receiver does not handle 1196 this option, or does not match the vendor ID in the option, then the 1197 option may be completely ignored by the receiver. The first 24 bits 1198 of the option's payload (following the length field) contains the 802 1199 vendor ID as assigned by the IEEE [5]. The remaining octets in the 1200 payload are vendor-dependent. 1202 6. Security Considerations 1204 As in any routing protocol, there are a number of potential security 1205 attacks possible, particularly denial-of-service attacks. The use of 1206 authentication on all packets is recommended to avoid such attacks. 1208 The authentication schemes described in this document are intended to 1209 allow the receiver of a packet to validate the identity of the 1210 sender; they do not provide privacy or protection against replay 1211 attacks. 1213 Detailed security analysis of this protocol is for further study. 1215 7. Discussion 1217 The result of an NHRP request depends on how routing is configured 1218 among the NHSs of an NBMA network. If the destination station is 1219 directly connected to the NBMA network and the NHSs always prefer 1220 NBMA routes over routes via other link layer networks, the NHRP 1221 replies always return the NBMA address of the destination station 1222 itself rather than the NBMA address of some egress router. For 1223 destinations outside the NBMA network, egress routers and routers in 1224 the other link layer networks should exchange routing information so 1225 that the optimal egress router is always found. 1227 When the NBMA next hop toward a destination is not the destination 1228 station itself, the optimal NBMA next hop may change dynamically. 1229 This can happen, for instance, when an egress router nearer to the 1230 destination becomes available. This change can be detected in a 1231 number of ways. First of all, the source station will need to 1232 periodically reissue the NHRP Request at a minimum just prior to the 1233 expiration of the holding timer, and most likely more aggressively 1234 than that. Alternatively, the source can be configured to receive 1235 routing information from its NHSs. When it detects an improvement in 1236 the route to the destination, the source can reissue the NHRP request 1237 to obtain the current optimal NBMA next hop. Source stations that 1238 are routers may choose to establish a routing association with the 1239 egress router, allowing the egress router to explicitly inform the 1240 source about changes in routing (and providing additional routing 1241 information, authentication, etc.) 1243 The dynamic nature of routing impacts caching strategies as well, 1244 since cached information may not be up-to-date. This is especially 1245 an issue when NHSs are deployed in server mode, since the NHSs may 1246 not be privy to routing information. However, stale cached 1247 information may only cause suboptimal routing (choosing the wrong 1248 egress point and taking extra hops across the NBMA network) rather 1249 than causing black holes. Cache management strategies are for 1250 further study. 1252 In addition to NHSs, an NBMA station could also be associated with 1253 one or more regular routers that could act as "connectionless 1254 servers" for the station. The station could then choose to resolve 1255 the NBMA next hop or just send the IP packets to one of its 1256 connectionless servers. The latter option may be desirable if 1257 communication with the destination is short-lived and/or doesn't 1258 require much network resources. The connectionless servers could, of 1259 course, be physically integrated in the NHSs by augmenting them with 1260 IP switching functionality. 1262 NHRP supports portability of NBMA stations. A station can be moved 1263 anywhere within the NBMA network and still keep its original IP 1264 address as long as its NHS(s) remain the same. Requests for 1265 authoritative information will always return the correct link layer 1266 address. 1268 8. Protocol Operation 1270 In this section, we discuss certain operational considerations of 1271 NHRP. 1273 8.1 Router-to-Router Operation 1275 In practice, the initiating and responding stations may be either 1276 hosts or routers. However, there is a possibility under certain 1277 conditions that a stable routing loop may occur if NHRP is used 1278 between two routers. This situation can be avoided if there are no 1279 "back door" paths between the entry and egress router outside of the 1280 NBMA network, and can be ameliorated by periodically reissuing the 1281 NHRP request. If these conditions cannot be satisfied, the use of 1282 NHRP between routers is not recommended. 1284 One approach to the router-to-router case that is being considered is 1285 to run a limited instance of a routing protocol between the two 1286 routers. Any routing protocol that provides loop detection may be 1287 used. This routing protocol instance will likely only carry a subset 1288 of the total routing information, and is unlikely to be closely 1289 integrated into the routing in which each of the routers is otherwise 1290 participating (due to the abitrary connectivity possible in such 1291 situations and its impact on the stability and quality of overall 1292 routing). This approach is for further study. 1294 8.2 Handling of IP Destination Address Field 1296 NHRP packets are self-contained in terms of the IP addressing 1297 information needed for protocol operation--the IP source and 1298 destination addresses in the encapsulating IP header are not used. 1299 However, the setting of the IP destination address field does impact 1300 how NHRP requests are forwarded. 1302 There are essentially three choices in how to set the destination IP 1303 address field at any particular point in the forwarding of an NHRP 1304 request: the ultimate destination being resolved, the next-hop IP 1305 router on the path to the destination, and the next-hop NHS (which 1306 might not be adjacent to the NHS forming the packet header). 1308 The first case, addressing the packet to the destination being 1309 resolved (in the hopes that an NHS lies along the path) is desirable 1310 for at least two reasons. It simplifies configuration (since the 1311 identity of the next NHS need not be known explicitly), and it 1312 simplifies deployment (since the packet will pass silently through 1313 routers that are not NHSs). However, it assumes that the serving NHS 1314 lies along the path to the destination, and it requires NHSs along 1315 the path to examine the packet even though it is not addressed to 1316 them. 1318 The second case, addressing the packet to the next-hop router, is 1319 similar to the first in that it follows the path to the destination, 1320 thus reducing configuration complexity. It furthermore only requires 1321 NHSs to process the packet if they are directly addressed. It too 1322 assumes that the responding NHS is on the path to the destination. 1323 However, it requires that all routers along the path are also NHSs. 1325 The third case, addressing the packet to the next-hop NHS, allows the 1326 NHSs to be independent of routing, and requires only addressed NHSs 1327 to examine the packet. However, there is no reasonable way, other 1328 than manual configuration, to determine the identity of the next hop 1329 NHS if it is not also the next hop IP router (making it option two). 1331 In order to balance all of these issues, the following rules shall be 1332 used when constructing IP packets to carry NHRP requests. 1334 Stations 1336 Stations shall address NHRP packets to the NHS by which they are 1337 served, regardless of whether NHRP has been deployed in Server mode 1338 or Fabric mode. 1340 NHSs 1341 If an NHS receives an NHRP packet in which the IP destination 1342 address does not match any of its own IP addresses, it shall 1343 process the NHRP packet as appropriate, and if it must forward the 1344 NHRP packet to another NHS, shall transmit the packet with the same 1345 IP destination address with which it was received. 1347 If an NHS receives an NHRP packet in which the IP destination 1348 address matches one of its own IP addresses, it shall process the 1349 NHRP packet as appropriate, and if it must forward the NHRP packet 1350 to another NHS, shall set the destination IP address in one of the 1351 following ways: 1353 If there is a configured next-hop NHS for the destination being 1354 resolved (Server mode), it shall transmit the packet with the IP 1355 destination address set to the next-hop NHS. 1357 If there is no configured next-hop NHS (Fabric Mode), it shall 1358 transmit the packet with the IP destination address set to the 1359 address of the destination being resolved, and shall include the 1360 Router Alert option [6] so that intermediate NHS/routers can 1361 examine the NHRP packet. 1363 8.3 Pseudocode 1365 TBD. 1367 References 1369 [1] NBMA Address Resolution Protocol (NARP), Juha Heinanen and Ramesh 1370 Govindan, draft-ietf-rolc-nbma-arp-00.txt. 1372 [2] Address Resolution Protocol, David C. Plummer, RFC 826. 1374 [3] Classical IP and ARP over ATM, Mark Laubach, RFC 1577. 1376 [4] Transmission of IP datagrams over the SMDS service, J. Lawrence 1377 and D. Piscitello, RFC 1209. 1379 [5] Assigned Numbers, J. Reynolds and J. Postel, RFC 1700. 1381 [6] IP Router Alert Option, Dave Katz, draft-katz-router-alert- 1382 00.txt. 1384 Acknowledgements 1386 We would like to thank Juha Heinenan of Telecom Finland and Ramesh 1387 Govidan of ISI for their work on NBMA ARP and the original NHRP 1388 draft, which served as the basis for this work. John Burnett of 1389 Adaptive, Dennis Ferguson of ANS, Joel Halpern of Newbridge, Paul 1390 Francis of NTT, and Tony Li and Bruce Cole of cisco should also be 1391 acknowledged for comments and suggestions that improved this work 1392 substantially. 1394 Authors' Addresses 1396 Dave Katz David Piscitello 1397 cisco Systems Core Competence 1398 170 W. Tasman Dr. 1620 Tuckerstown Road 1399 San Jose, CA 95134 USA Dresher, PA 19025 USA 1401 Phone: +1 408 526 8284 Phone: +1 215 830 0692 1402 Email: dkatz@cisco.com Email: dave@corecom.com