idnits 2.17.00 (12 Aug 2021) /tmp/idnits2967/draft-ietf-ion-r2r-nhrp-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 213 has weird spacing: '...tion in a tra...' == Line 227 has weird spacing: '...ermines that ...' == Line 232 has weird spacing: '...rmation to ch...' -- 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 (May 1998) is 8765 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internetworking Over NBMA Yakov Rekhter 2 INTERNET-DRAFT Cisco Systems 3 Joel Halpern 4 Expiration Date: November 1999 Institutional Venture Partners 5 May 1998 7 NHRP for Destinations off the NBMA Subnetwork 9 draft-ietf-ion-r2r-nhrp-03.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 The NBMA Next Hop Resolution Protocol (NHRP) [1] specifies a 33 mechanism that allows a source station (e.g., a host or a router) on 34 an NBMA subnetwork to find the NBMA subnetwork address of a 35 destination station when the destination station is connected to the 36 NBMA subnetwork. For the case where the destination station is off 37 the NBMA subnetwork the mechanism described in [1] allows a node to 38 determine the NBMA subnetwork address of an egress router from the 39 NBMA subnetwork that is ``nearest'' to the destination station. If 40 used to locate an egress router wherein the destination station is 41 directly behind the egress router, the currently documented NHRP 42 behaviors are sufficient. However, as documented elsewhere [2], 43 there are cases where if used between routers for generalized 44 transit, NHRP can produce loops. 46 This document describes extensions to the NBMA Next Hop Resolution 47 Protocol (NHRP) [1] that allow a node to acquire and maintain the 48 information about the egress router without constraining the 49 destination(s) to be directly connected to the egress router. 51 3. CONVENTIONS 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [3]. 57 4. NHRP Target Information 59 The mechanism described in this document allows a node to find an 60 egress router for either a single destination, or a set of 61 destinations (where the set is expressed as a single address prefix). 62 Since a single destination is just a special case of a set of 63 destinations, for the rest of the document we will always talk about 64 a set of destinations, and will refer to this set as an ``NHRP 65 target''. 67 The NHRP target is carried in the NHRP Request, Reply, and Purge 68 messages as an address prefix (using the Prefix Length field of the 69 NHRP Client Information Extension). In order to ensure correctness, 70 a target may be replaced by an identical target with a longer prefix 71 length. This replacement may be done at an intermediate or 72 responding NHS. Other than this increase of prefix length, no NHS 73 shall modify the NHRP target information in an NHRP message. 75 In general a router may maintain in its Forwarding Information Base 76 (FIB) routes whose Network Layer Reachability Information (NLRI) that 77 exhibits a subset relation. Such routes are called overlapping 78 routes. To expand upon this, entries in a FIB are often related, with 79 one entry being a prefix of another entry. The longer prefix 80 therefore covers a set of routes that are a subset of the shorter 81 prefix. To provide correct forwarding in the presence of such 82 overlapping (or nested) routes this document constrains an NHRP 83 target by requiring that all the destinations covered by the target 84 must form a subset of the NLRI of at least one route in the 85 Forwarding Information Base (FIB) of the router that either 86 originates, or propagates an NHRP Request. That is, there must be at 87 least one route in the FIB which is a prefix of (or equal to) the 88 target of the request. For the rest of the document we'll refer to 89 this as the ``first NHRP target constraint''. A station can 90 originate an NHRP Request, and a router can propagate an NHRP Request 91 only if the NHRP target of the Request does not violate the first 92 NHRP target constraint. 94 If a received NHRP request does not meet this ``first NHRP target 95 constraint'' when received, the receiving router has two choices. It 96 may answer the request, defining itself as the egress. This is 97 compatible with the base NHRP specification, and preserves the 98 ``first NHRP target constraint''. Alternatively, the router may 99 lengthen the received prefix until the first constraint is met. The 100 prefix is lengthened until the target falls within (or becomes equal 101 to) a FIB entry. 103 A route (from a local FIB) whose NLRI forms a minimal superset of all 104 the destinations covered by the NHRP target is called an ``NHRP 105 forwarding route''. This is the longest FIB entry that covers the 106 entire target. Observe that by definition the set of destinations 107 covered by an NHRP target always exhibits a subset relation to the 108 set of destinations covered by the NHRP forwarding route associated 109 with the target. 111 This document further constrains origination/propagation of NHRP 112 Requests by prohibiting the NHRP target (carried by a Request) to 113 form a superset of the destinations covered by any of the routes in 114 the local FIB. Remembering that there are nested FIB entries, this 115 constraint says that there must not be a FIB entry which is itself a 116 subset of the target of the NHRP request. If there were, there would 117 be some destinations within the request which would be forwarded 118 differently then others, preventing a single answer from being 119 correct. The constraint applies both to the station that originates 120 an NHRP Request and to the routers that propagate the Request. For 121 the rest of the document we'll refer to this constraint as the 122 ``second NHRP target constraint''. A station can originate an NHRP 123 Request, and a router can propagate an NHRP Request only if the NHRP 124 target of the Request does not violate the second NHRP target 125 constraint. The second NHRP target constraint guarantees that 126 forwarding to all the destinations covered by the NHRP target would 127 be accomplished via a single (common) route, and this route would be 128 the NHRP forwarding route for the target. 130 Again, if a received NHRP request does not meet the ``second NHRP 131 target constraint'', the router may either respond to the request, 132 providing its own NBMA address, or it may lengthen the prefix in the 133 request so as to meet the second constraint. 135 5. NHRP Requester and Terminator Processing 137 The issue being addressed with the behaviors being mandated in this 138 document is to ensure that sufficient information is present and 139 processed to avoid NHRP shortcuts causing packet forwarding loops. 141 In order to do this, the requester and responder of the request must 142 undertake certain work, and any "border routers" in the forwarding 143 path must also perform certain additional work beyond checking the 144 target consistency with the FIB during request processing. This 145 border work suffices to detect any changes that would cause the path 146 selection to have failed the target constraints. 148 The work performed by the requester and responder consists of two 149 kinds of work. One set is requester only work, and is required in 150 order to determine where the protocol boundaries are. The other set 151 is the route monitoring work. 153 5.1. NHRP IGP information 155 The primary cause of NHRP forwarding loops is the loss of information 156 at a routing protocol boundary. Normally, such boundaries are 157 detected by the router at the boundary. However, it is possible for 158 IGP boundaries to overlap. Therefore, NHRP requesting Routers MUST 159 include the NHRP IGP Information extension (as defined in section 9). 160 This extension indicates what IGP the originator of the request uses. 161 A requesting router must always include this extension, since it is 162 not possible to tell a priori whether the eventual resolution of the 163 request will be a host or a router. 165 Because the entire BGP domain is consider one routing domain, the 166 extension also contains an indication as to whether the originator 167 was a BGP speaker. 169 5.2. NHRP Requestor and Responder monitoring 171 NHRP requestors and responders are required to monitor routing to 172 maintain correct shortcut information. 174 Once a router that originates an NHRP Request acquires the shortcut 175 next hop information, it is essential for the router to be able to 176 detect any changes that would affect the correctness of this 177 information. The following measures are intended to provide the 178 correctness. 180 Both ends of a shortcut have to monitor the status of the route that 181 was associated with the shortcut (the NHRP forwarding route). If the 182 status changes at the router that generated the NHRP Reply, this 183 router should send a Purge message, so that the NHRP Requester would 184 issue another NHRP. If the status changes at the Requester, the 185 Requester must issue another NHRP. This ensures that when both ends 186 of a shortcut are up, any changes in routing that impact forwarding 187 to any of the destinations in the NHRP target would result in a 188 revalidation (via NHRP) of the shortcut. Note that in addition to 189 sending purges/reverifies in response to routing changes which 190 directly effect the NHRP target, there is one other case. 192 A router MUST perform the appropriate purge/reverification process if 193 it receives routing updates that cause an issued NHRP request to 194 violate either of the target constraints defined earlier. This is 195 possible at an NHRP originator, and is more likely at border devices. 197 Once a shortcut is established, the Requester needs to have some 198 mechanism(s) to ensure that the other end of the shortcut is alive. 199 Among the possible mechanisms are: (a) indications from the Data Link 200 layer, (b) presence of traffic in the reverse direction that comes 201 with the Link Layer address of the other end, (c) keepalives sent by 202 the other end. This is intended to suppress black holes, when the 203 next hop router in the shortcut (the router that generated Reply) 204 goes down. 206 A requester should establish a shortcut only after the requester 207 determines that the information provided by NHRP is fairly stable. 208 This is necessary in order to avoid initiating shortcuts that are 209 based on transients in the routing information, and thus would need 210 to be revalidated almost immediately anyway. Thus, a router may wait 211 to use NHRP information if the underlying routing information has 212 recently changed. If the routing protocol being used has a notion of 213 stability, it should be used. Information in a transient or 214 holddown state SHOULD NOT be used, and requests which need to be 215 processed based on such information SHOULD be discarded. 217 6. Border Processing of NHRP Request 219 Processing of an NHRP Request is covered by two sets of rules: the 220 first set for IGP related processing, and the second set for BGP 221 related processing. The rules for IGP processing relate to 222 determining where the IGP borders are (in particular in the case of 223 overlapping IGPs), and then for what must happen at said borders. 225 6.1. Border Determination 227 When a router receives a request, and determines that it is not the 228 NBMA exit router, it must perform a series of checks before 229 forwarding the request. 231 When a router receives such a Request, the router uses the NHRP 232 target and the NHRP IGP information to check whether (a) the first 233 and the second NHRP target constraints are satisfied, (b) the router 234 it is in the same routing domain as the originator of the Request, 235 and if yes, then whether (c) it is a border router for that domain. 237 When the NHRP target is checked against the forwarding database, a 238 determination must be made as to whether either of the target 239 constraints has been violated. If they are violated, then the router 240 MAY either 242 o Extend the prefix so as to meet the constraints. 244 o reply to the request indicating that it is the destination 246 o return an error indicating which constraint was violated. 248 If the NHRP forwarding route indicates a next hop that is not on the 249 same NBMA as the interface on which the Request was received, the 250 router sends back an NHRP Reply and terminates the query. 252 If a router receives a request without IGP information, then it was 253 originated within this domain by a host. If the router is an AS 254 Border Router (i.e. running BGP), and if the forwarding path exits 255 the AS, then it must behave as a border router for this request. 256 Otherwise, for requests without IGP information, the router is not a 257 border router. 259 For requests with IGP information, the router compares the forwarding 260 information against the IGP in the request. If the forwarding entry 261 indicates that the next hop is to exit the AS (an AS Border Router), 262 then check the BGP behaviors below. 264 When the IGP the next hop was learned from is the same IGP as 265 indicated in the request, then the NHS simply forwards the request. 266 [Of course, as per NHRP, it is free to respond indicating it is the 267 termination of the shortcut, for example when the Router/NHS is a 268 firewall.] 270 When the IGP the next hop was learned from is different from that 271 listed in the NHRP request, then this NHS is a border router for this 272 request. 274 6.2. Border Behavior 276 In all cases, a border router has two choices. It MAY terminate and 277 respond to the request, responding with its IP and NBMA address. 279 Alternatively, it MAY perform border propagation. 281 6.2.1. Reorigination 283 Upon receiving an NHRP request for which the NHS is a border router, 284 if it chooses to propagate the request, it MUST originate a new NHRP 285 request. This request will have a locally generated request 286 identifier, and the same NHRP target information as in the received 287 request. The NHRP IGP Information will be the correct indication for 288 the outgoing interface, with BGP indication if the received request 289 had the BGP indication, or if this transition crosses the AS border. 290 All other extensions are copied from the incoming request to the new 291 request. 293 6.2.2. Response Propagation 295 When an NHRP response is received for a propagated request, the 296 information is copies from the received request, and passed on in a 297 new NHRP response, responding to the originally received request. 298 The prefix length in the received response is copied to the new 299 response. All extensions except the NHRP IGP Information are copied 300 to the new response. 302 In addition, the border router saves state about this information 303 exchange. The saved state includes the NHRP target from the 304 response, with the NHRP prefix length that resulted from the 305 exchange. It also includes the both the original requester, and the 306 identity of the responder. These are used to generate appropriate 307 reverification and purges whenever routing changes in a way that 308 could effect the resolution. 310 6.3. Border Information 312 Sometimes the routing protocol will have provided the border router 313 with enough information to generate a response to an incoming NHRP 314 request. In particular, the border router may have information about 315 IP prefix to NBMA address bindings. If such information is present, 316 it may be used by a border router to produce an NHRP response without 317 actually propagating the request. In such a case, that information 318 must be monitored for stability to maintain the correctness of the 319 shortcut. 321 7. BGP Operation 323 While the NHRP mechanism described above is mostly constrained to the 324 routers within a single routing domain, the same mechanisms can be 325 used for shortcuts that span multiple domains. In doing so, one 326 wants to produce as little additional overhead in the BGP space as 327 possible. 329 Therefore, we will treat the space over which BGP runs as a single 330 routing domain. Care must be taken to propagate information across 331 the individual AS without error, and to indicate that one has 332 properly entered the BGP space. 334 Additional complexity in handling multi-domain shortcuts arise if 335 routing information gets aggregated at the border routers (which 336 certainly happens in practice). Since BGP is the major protocol that 337 is used to exchange routing information across multiple routing 338 domains, we'll restrict our proposal to the case where the routing 339 information exchange across domains' boundaries is controlled by BGP. 341 If both the source and the destination domains are on a common NBMA 342 network, and the path between these two domains is also fully within 343 the same NBMA network, then we have only three routing domains to 344 deal with: source routing domain, BGP routing domain, and destination 345 routing domain. If the destination domain is not on the same NBMA as 346 the source domain, then we need to deal only with two domains - the 347 source and the BGP. Note that we treat all routers that participate 348 in a single (common) instance of BGP as a single BGP routing domain, 349 even if these routers participate in different intra-domain routing 350 protocols, or in different instances of the same intra-domain routing 351 protocol. There are three aspects to consider. 353 (a) how a border router in the domain that the originator of 354 the Request is in handles the Request (crossing IGP/BGP 355 boundary), 357 (b) how the Request is handled across the BGP domain, and 358 finally 360 (c) how a border router in the domain where the NHRP target is 361 in handles the Request (crossing BGP/IGP boundary). 363 7.1. Handling NHRP Request at the source domain border router 365 When a border router receives an NHRP Request originated from within 366 its own (IGP) routing domain, the border router determines the NHRP 367 forwarding route for the NHRP target carried by the Request. If the 368 router already has the shortcut information for the forwarding route, 369 then the router uses this information to construct a Reply to the 370 source of the NHRP Request. Otherwise, the router originates its own 371 NHRP Request. The Request contains exactly the same NHRP target, as 372 was carried by the original Request; The NHRP IGP Information will 373 indicate that the request was generated by BGP, and will indicate the 374 IGP of the BGP AS being entered. While it is assumed that a BGP 375 transit AS will generally use only one IGP, the IGP information (and 376 border processing) is included to allow all cases. The newly 377 originated Request is sent to the next hop of the NHRP forwarding 378 route. Once the border router receives a Reply to its own Request, 379 the border router uses the next hop information from the Reply to 380 construct its own Reply to the source of the original NHRP Request. 382 If the border router later on receives a Purge message for the NHRP 383 forwarding route, the border router treats this event as if there was 384 a local change in the NHRP forwarding route (even if the there was no 385 changes in the route). 387 This is exactly the same behavior as all other border cases, and is 388 described here for completeness. 390 7.2. Handling NHRP Request within the BGP domain 392 Routers within an AS will check the IGP, and perform appropriate 393 processing based on the IGP match. In general, this will result in 394 normal forwarding of the NHRP request. 396 Therefore, the significant cases occur at the BGP speaking routers. 397 There are two conditions to check for, early exit of the NBMA, and 398 reachability aggregation. Both of these conditions apply to 399 Autonomous systems that do not contain the NHRP target. 401 7.2.1. NBMA exit 403 The BGP router in deciding where to send the NHRP request will 404 determine what the correct exit from the autonomous system is. It 405 will determine if that exit is within the NBMA. If it is not within 406 the NBMA, then the router MUST respond to the NHRP request, 407 indicating its own IP and NBMA addresses as the correct termination 408 of the shortcut. This is because the actual NBMA border device is 409 not in a position to monitor the topology properly. 411 BGP routers within an NBMA which are supporting R2R NHRP SHOULD be 412 configured to know where the NBMA border is. In the absence of such 413 configuration, requests from other router SHOULD be terminated at the 414 BGP router, since it can not tell what will be crossing the border. 415 A BGP router supporting R2R NHRP may be configured to assume that all 416 of its neighbors are within the NBMA, and therefore not perform such 417 early termination. 419 7.2.2. Reachability Aggregation 421 BGP routers aggregate reachability. If the router aggregates 422 reachability that includes the NHRP target, only this router has the 423 visibility to some of the topology changes that can affect the 424 correctness of the route. Therefore, this router is a border router 425 for this NHRP request. 427 It must originate a new request, place the correct information in the 428 request, receive the response, and generate the correct response 429 towards the requester. This aggregating router must also monitor 430 routing in case of changes which affect the request. 432 If the router later on receives a Purge message for the NHRP 433 forwarding route, the router treats this event as if there was a 434 change in the NHRP forwarding route (even if the there was no changes 435 in the route). 437 It should be noted that this conditions applies if the router COULD 438 aggregate relevant routing information, even if it currently does 439 not. 441 7.3. Handling NHRP Request at the destination domain border router 443 When a border router receives an NHRP Request from a BGP speaker, and 444 the border router determines that all the destinations covered by the 445 NHRP target of the Request are within the (IGP) domain of that border 446 router, the border router determines the NHRP forwarding route for 447 the NHRP target carried by the Request. The newly formed Request 448 contains exactly the same NHRP target as the received Request; the 449 NHRP IGP Information indicates the IGP this router is using to select 450 the route to the destination. The newly originated Request is sent 451 to the next hop of the NHRP forwarding route. Once the border router 452 receives a Reply to its own Request, the border router uses the next 453 hop information from the Reply to construct its own Reply to the 454 source of the original NHRP Request. 456 If the border router later on receives a Purge message for the NHRP 457 forwarding route, the border router treats this event as if there was 458 a change in the NHRP forwarding route (even if the there was no 459 changes in the route). 461 8. More state, less messages 463 It should be possible to reduce the number of Purge messages and 464 subsequent NHRP messages (caused by the Purge messages) by 465 maintaining more state on the border routers at the source and 466 destination domains, and the BGP routers that perform aggregation 467 along the path from the source to the destination. 469 Specifically, on these routers it would be necessary to keep the 470 information about all the NHRP targets for which the routers maintain 471 the shortcut information. This way when such a router determines 472 that the NHRP forwarding route (for which the router maintains the 473 shortcut information) changes due to some local routing changes, the 474 router could check whether these local changes impact forwarding to 475 the destinations covered by the NHRP targets. For the targets that 476 are impacted by the changes the router would send Purge messages. 478 Note that this mechanism (maintaining NHRP targets) precludes the use 479 of Address Prefix Extension - the shortcut will be determined only 480 for the destinations covered by the NHRP target (so, if the target is 481 a single IP address, then the shortcut would be determined only for 482 this address). 484 9. NHRP IGP Information Extension Format 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 0-3 |C|u| Type = 9 | Length = 4 | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 4-7 | flags |b| Reserved | IGP ID | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 C "Compulsory." If clear, and the NHS does not recognize the 495 type code, the extension maybe safely be ignored. For 496 the IGP Information extension, this bit is clear. 498 u Unused and must be set to zero 500 Type The extension type code. For the IGP Information 501 extension, this is 9. 503 Length the length in octets of the value. For this extension, 504 this is 4. 506 flags Other than the "b" flag, these are reserved, SHALL be set 507 to 0 on transmission, and SHALL be ignored on reception. 509 b This flag indicates whether the request (or a predecessor 510 thereof) was originated by a BGP speaker. Set (to 1) to 511 indicate that the BGP speaker has operated on this. 512 Clear (to 0) if not. 514 IGP ID This field indicates the IGP used by the request 515 originator. The currently defined values are: 517 1 = RIP 518 2 = RIPv2 519 3 = OSPF 520 4 = Dual IS-IS 522 10. IANA Considerations 524 This document defines an enumerated field for identifying IGPs in 525 router-to-router NHRP requests. Since there may be additional IGPs 526 in use, a procedure is needed for allocating additional values. The 527 IANA shall allocate values for this field as needed. Specifically, 528 when requested a value shall be allocated for an IGP for any layer 3 529 protocol for which there is a clear and stable definition of the 530 protocol. An RFC is the best example of such stability. Vendor 531 published specifications are also acceptable. The IANA should avoid 532 issuing two values for the same protocol. However, it is not 533 incumbent upon the IANA to determine if two similar protocols are 534 actually the same. 536 11. Open issues 538 The mechanisms described in this document assume that certain routers 539 along a path taken by an NHRP Request would be required to maintain 540 state associated with the NHRP forwarding route associated with the 541 NHRP target carried by the Request. However, it is quite clear that 542 the router(s) may also lose this state. Further study of the impact 543 of losing the state is needed before advancing the use of NHRP for 544 establishing shortcuts among routers beyond Proposed Standard. 546 The mechanisms described in this document may result in a situation 547 where a router would be required to maintain NHRP peering with 548 potentially a fairly large number of other routers. Further study is 549 needed to understand the implications of this on the scalability of 550 the approach where NHRP is used to establish shortcuts among routers. 552 This document doesn't have a proof that the mechanisms described here 553 result in loop-free steady state forwarding when NHRP is used to 554 establish shortcuts among routers, however, a counterexample has not 555 yet been found. Further analysis should be done as part of advancing 556 beyond Proposed Standard. 558 12. Security Considerations 560 Security is provided in the base NHRP protocol, using hop-by-hop 561 authentication. There is no change to the fundamental security 562 capabilities provided therein when these extensions are used. It 563 should be noted that the assumption of transitive trust that is the 564 basis of such security may well be significantly weaker in an inter- 565 domain environment, and administrators of border routers should take 566 this into consideration. The hop-by-hop security model is used by 567 NHRP originally because there is no end-to-end security association 568 between the requesting and responding NHRP entities. In this 569 environment there is the additional facet that intermediate NHS are 570 modifying the prefix length field of the CIE, thus changing the end- 571 to-end information. 573 13. References 575 [1] J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy., 576 "NBMA Next Hop Resolution Protocol", RFC-2332, USC/Information 577 Sciences Institute, April 1998. 579 [2] D. Cansever., "NHRP Protocol Applicability Statement", RFC-2333, 580 USC/Information Sciences Institute, April 1998 582 [3] S. Bradner., "Key words for use in RFCs to Indicate Requirement 583 Levels", RFC-2119, USC/Information Sciences Institute, March 1997. 585 14. Acknowledgements 587 The authors wish to Thank Curtis Villamizer for his contributions 588 emphasizing both the importance of the looping cases, and some 589 examples of when loops can occur. 591 15. Author Information 592 Joel M. Halpern 593 Institutional Venture Partners 594 3000 Sand Hill Road 595 Menlo Park, CA 596 Phone: (650) 926-5633 597 email: joel@mcquillan.com 599 Yakov Rekhter 600 cisco Systems, Inc. 601 170 Tasman Dr. 602 San Jose, CA 95134 603 Phone: (914) 528-0090 604 email: yakov@cisco.com