idnits 2.17.1 draft-halpern-ion-r2r-nhrp-00.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 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 212 has weird spacing: '...ermines that ...' == Line 217 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 (June 1998) is 9444 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: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internetworking Over NBMA Yakov Rekhter 3 INTERNET-DRAFT Cisco Systems 4 Joel Halpern 5 Expiration Date: December 1998 Newbridge Networks, Inc. 6 June 1998 8 NHRP for Destinations off the NBMA Subnetwork 10 draft-halpern-ion-r2r-nhrp-00.txt 12 1. Status of this Memo 14 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 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 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 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 document 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 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 to find an egress 60 router for either a single destination, or a set of destinations 61 (where the set is expressed as a single address prefix). Since a 62 single destination is just a special case of a set of destinations, 63 for the rest of the document we will always talk about a set of 64 destinations, and will refer to this set as an ``NHRP target''. 66 The NHRP target is carried in the NHRP Request, Reply, and Purge 67 messages as an address prefix (using the Destination Prefix Length 68 extension). In order to ensure correctness, a target may be replaced 69 by an identical target with a longer prefix length. Other than this 70 increase of prefix length, no NHS shall modify the NHRP target 71 information in an NHRP message. 73 In general a router may maintain in its Forwarding Information Bas 74 (FIB) routes whose Network Layer Reachability Information (NLRI) that 75 exhibits a subset relation. Such routes are called overlapping 76 routes. To provide correct forwarding in the presence of overlapping 77 routes this document constrains an NHRP target by requiring that all 78 the destinations covered by the target must form a subset of the NLRI 79 of at least one route in the Forwarding Information Base (FIB) of the 80 router that either originates, or propagates an NHRP Request. For the 81 rest of the document we'll refer to this as the ``first NHRP target 82 constraint''. A station can originate an NHRP Request, and a router 83 can propagate an NHRP Request only if the NHRP target of the Request 84 does not violate the first NHRP target constraint. 86 If a received NHRP request does not meet this ``first NHRP target 87 constrant'' when received, the receiving router has two choices. It 88 may answer the request, defining itself as the egress. This is 89 compatible with the base NHRP specification, and preserves the 90 ``first NHRP target constraint''. Alternatively, the router may 91 lengthen the received prefix until the first constraint is met. 93 A route (from a local FIB) whose NLRI forms a minimal superset of all 94 the destinations covered by the NHRP target is called an ``NHRP 95 forwarding route''. Observe, that by definition the set of 96 destinations covered by an NHRP target always exhibits a subset 97 relation to the set of destinations covered by the NHRP forwarding 98 route associated with the target. 100 This document further constrains origination/propagation of NHRP 101 Requests by prohibiting the NHRP target (carried by a Request) to 102 form a superset of the destinations covered by any of the routes in 103 the local FIB. The constraint applies both to the station that 104 originates an NHRP Request and to the routers that propagate the 105 Request. For the rest of the document we'll refer to this constraint 106 as the ``second NHRP target constraint''. A station can originate an 107 NHRP Request, and a router can propagate an NHRP Request only if the 108 NHRP target of the Request does not violate the second NHRP target 109 constraint. The second NHRP target constraint guarantees that 110 forwarding to all the destinations covered by the NHRP target would 111 be accomplished via a single (common) route, and this route would be 112 nothing, but the NHRP forwarding route for the target. 114 Again, if a received NHRP request does not meet the ``second NHRP 115 target constraint'', the router may either respond to the request, 116 providing its own NBMA address, or it may lengthen the prefix in the 117 request so as to meet the second constraint. 119 5. NHRP Requester and Terminator Processing 121 The issue being addressed with the behaviors being mandated in this 122 document is to ensure that sufficient information is present and 123 processed to avoid NHRP shortcuts causing packet forwarding loops. 125 In order to do this, the requester and responder of the request must 126 undertake certain work, and any "border routers" in the forwarding 127 path must also perform certain work. 129 The work performed by the requester and responder consists of two 130 kinds of work. One set is requester only work, and is required in 131 order to determine where the protocol boundaries are. The other set 132 is the route monitoring work. 134 5.1. NHRP IGP information 136 The primary cause of NHRP forwarding loops is the loss of information 137 at a routing protocol boundary. Normally, such boundaries are 138 detected by the router at the boundary. However, it is possible for 139 IGP boundaries to overlap. Therefore, NHRP requesting Routers MUST 140 include the NHRP IGP Identifier extension. This extension indicates 141 what IGP the originator of the request uses. This extension must 142 always be included by a requesting router, since it is not possible 143 to tell a priori whether the eventual resolution of the request will 144 be a host or a router. 146 Because the entire BGP domain is consider one routing domain, the 147 extension also contains an indication as to whether the originator 148 was a BGP speaker. 150 5.2. NHRP Requestor and Responder monitoring 152 NHRP requestors and responders are required monitor routing to 153 mainting correct shortcut information. 155 Once a router that originates an NHRP Request acquires the shortcut 156 next hop information, it is essential for the router to be able to 157 detect any changes that would affect the correctness of this 158 information. The following measures are intended to provide the 159 correctness. 161 Both ends of a shortcut have to monitor the status of the route that 162 was associated with the shortcut (the NHRP forwarding route). If the 163 status changes at the router that generate the NHRP Reply, this 164 router should send a Purge message, so that the NHRP Requester would 165 issue another NHRP. If the status changes at the Requester, the 166 Requester must issue another NHRP. This allows to ensure that when 167 both end of a shortcut are up, any changes in routing that impact 168 forwarding to any of the destination in the NHRP target would result 169 in a revalidation (via NHRP) of the shortcut. Note that in addition 170 to sending purges/reverifies in response to routing changes which 171 directly effect the NHRP target, there is one other case. 173 A router MUST perform the appropriate purge/reverification process if 174 it receives routing updates which case an issued NHRP request to 175 violate either of the the target constraints defined earlier. This 176 is possible at an NHRP originator, and is more likely at border 177 devices. 179 Once a shortcut is established, the Requester needs to have some 180 mechanism(s) to ensure that the other end of the shortcut is alive. 182 Among the possible mechanisms are: (a) indications from the Data Link 183 layer, (b) presence of traffic in the reverse direction that comes 184 with the Link Layer address of the other end, (c) keepalives sent by 185 the other end. This is intended to suppress black holes, when the 186 next hop router in the shortcut (the router that generated Reply) 187 goes down. 189 A requester should establish a shortcut only after the requester 190 determines that the information provided by NHRP is fairly stable. 191 This is necessary in order to avoid initiating shortcuts that are 192 based on transients routing information, and thus would need to be 193 revalidated almost immediately anyway. 195 [Discussion: Should a router forward an NHRP Request based on a route 196 that is in a transient (e.g., holddown) state, or should the Request 197 be discarded ?] 199 [Discussion: what are the criteria to determine whether the 200 information provided by NHRP is "fairly stable" ?] 202 6. Border Processing of NHRP Request 204 Processing of an NHRP Request is covered by two sets of rules: the 205 first set for IGP related processing, and the second set for BGP 206 related processing. The rules for IGP processing relate to 207 determining where the IGP borders are (in particular in the case of 208 overlapping IGPs), and then for what must happen at said borders. 210 6.1. Border Determination 212 When a router receives a request, and determines that it is not the 213 NBMA exit router, it must perform a seris of checks before forwarding 214 the request. 216 When a router receives such a Request, the router uses the NHRP 217 target and the NHRP IGP information to check whether (a) the first 218 and the second NHRP target constraints are satisfied, (b) the router 219 it is in the same routing domain as the originator of the Request, 220 and if yes, then whether (c) it is a border router for that domain. 222 When the NHRP target is checked against the forwarding database, a 223 determination must be made as to whether either of the target 224 constraints have been violated. If they are violated, then the 225 router MAY either 226 o Extend the prefix so as to meet the constraints. 228 o replay to the request indicating that it is the destination 230 o return an error indicating which constraint was violated. 232 If the NHRP forwarding route indicates next hop that is not on the 233 same NBMA as the interface on which the Request was received, the 234 router sends back an NHRP Reply and terminates the query. 236 If a router receives a request without IGP information, then it was 237 originated within this domain by a host. If the router is an AS 238 Border Router (ie running BGP), and if the forwarding path exits the 239 AS, then it must behave as a border router for this request. 240 Otherwise, for requests without IGP information, the router is not a 241 border router. 243 For requests with IGP information, the router compares the forwarding 244 information against the IGP in the request. If the forwarding entry 245 indicates that the next hop is to exit the AS (an AS Border Router), 246 then check the BGP behaviors below. 248 When the IGP the next hop was learned from is the same IGP as 249 indicated in the request, then the NHS simply forwards the request. 250 [Of course, as per NHRP, it is free to respond indicating it is the 251 termination of the shortcut, for example when the Router/NHS is a 252 firewall.] 254 When the IGP the next hop was learned fromis different from that 255 listed in the NHRP request, then this NHS is a border router for this 256 request. 258 6.2. Border Behavior 260 In all cases, a border router has two choices. It MAY terminate and 261 respond to the request, responding with its IP and NBMA address. 263 Alternatively, it MAY perform border propagation. 265 6.2.1. Reorigination 267 Open receiving an NHRP request for which the NHS is a border router, 268 if it chooses to propogate the request, it MUST originate a new NHRP 269 request. This request will have a locally generated request 270 identifier, and the same NHRP target information as in the received 271 request. The NHRP IGP Information will be the correct indication for 272 the outgoing interface, with BGP indication if the received request 273 had the BGP indication, or if this transition crosses the AS border. 274 All other extensions are copied from the incoming request to the new 275 request. 277 6.2.2. Response Propagation 279 When an NHRP response is received for a propagated request, the 280 information is copies from the received request, and passed on in a 281 new NHRP response, responding to the originally received request. 282 The prefix length in the received response is copied to the new 283 response. All extensions except the NHRP IGP Information are copied 284 to the new response. 286 In addition, the border router saves state about this information 287 exchange. The saved state includes the NHRP target from the 288 response, with the NHRP prefix length that resulted from the 289 exchange. It also includes the both the original requester, and the 290 identity of the responder. These are used to generate appropriate 291 reverification and purges whenever routing changes in a way that 292 could effect the resolution. 294 6.3. Border Information 296 Somtimes the routing protocol will have provided the border router 297 with enough information to generate a response to an incoming NHRP 298 request. In particular, the border router may have information about 299 IP prefix to NBMA address bindings. If such information is present, 300 it may be used by a border router to produce an NHRP response without 301 actually propagating the request. In such a case, that information 302 must be monitorred for stability to maintain the correctness of the 303 shortcut. 305 7. BGP Operation 307 While the NHRP mechanism described above is mostly constrained to the 308 routers within a single routing domain, the same mechanisms can be 309 used for shortcuts taht span multiple domains. In doing so, one 310 wants to produce as little additional overhead in the BGP space as 311 possible. 313 Therefore, we will treat the space over which BGP runs as a single 314 routing domain. Care must be taken to propagate information across 315 the individual AS without error, and to indicate that one has 316 properly entered the BGP space. 318 Additional complexity in handling multi-domains shortcuts arise if 319 routing information gets aggregated at the border routers (which 320 certainly happens in practice). Since BGP is the major protocol that 321 is used to exchange routing information across multiple routing 322 domains, we'll restrict our proposal to the case where the routing 323 information exchange across domains' boundaries is controlled by BGP. 325 If both the source and the destination domains are on a common NBMA 326 network, and the path between these two domains is also fully within 327 the same NBMA network, then we have only three routing domains to 328 deal with: source routing domain, BGP routing domain, and destination 329 routing domain. If the destination domain is not on the same NBMA as 330 the source domain, then we need to deal only with two domains - the 331 source and the BGP. Note that we treat all routers that participate 332 in a single (common) instance of BGP as a single BGP routing domain, 333 even if these routers participate in different intra-domain routing 334 protocols, or in different instances of the same intra-domain routing 335 protocol. 337 (a) how a border router in the domain that the originator of 338 the Request is in handles the Request (crossing IGP/BGP 339 boundary), 341 (b) how the Request is handled across the BGP domain, and 342 finally 344 (c) how a border router in the domain where the NHRP target is 345 in handles the Request (crossing BGP/IGP boundary). 347 7.1. Handling NHRP Request at the source domain border router 349 When a border router receives an NHRP Request originated from within 350 its own (IGP) routing domain, the border router determines the NHRP 351 forwarding route for the NHRP target carried by the Request. If the 352 router already has the shortcut information for the forwarding route, 353 then the router uses this information to construct a Reply to the 354 source of the NHRP Request. Otherwise, the router originates its own 355 NHRP Request. The Request contains exactly the same NHRP target, as 356 was carried by the original Request; The NHRP IGP Information will 357 indicate that the request was generated by BGP, and will indicate the 358 IGP of the BGP AS being entered. While it is assumed that a BGP 359 transit AS will generally use only one IGP, the IGP information (and 360 border processing) is included to allow all cases. The newly 361 originated Request is sent to the next hop of the NHRP forwarding 362 route. Once the border router receives a Reply to its own Request, 363 the border router uses the next hop information from the Reply to 364 construct its own Reply to the source of the original NHRP Request. 366 If the border router later on receives a Purge message for the NHRP 367 forwarding route, the border router treats this event as if there was 368 a local change in the NHRP forwarding route (even if the there was no 369 changes in the route). 371 This is exactly the same behavior as all other border cases, and is 372 described here for completeness. 374 7.2. Handling NHRP Request within the BGP domain 376 Routers within an AS will check the IGP, and perform appropriate 377 processing based on the IGP match. In general, this will result in 378 normal forwarding of the NHRP request. 380 Therefore, the significant cases occur at the BGP speaking routers. 381 There are two conditions to check for, early exit of the NBMA, and 382 reachability aggregation. Both of these conditions appply to 383 Automnomous systems which do not contain the NHRP target. 385 7.2.1. NBMA exit 387 The BGP router in deciding where to send the NHRP request will 388 determine what the correct exit from the autonomous system is. It 389 will determine if that exit is within the NBMA. If it is not within 390 the NBMA, then the router MUST respond to the NHRP request, 391 indicating its own IP and NBMA addresses as the correct termination 392 of the shortcut. This is because the actual NBMA border device is 393 not in a position to monitor the topology properly. 395 [Discussion: Should we also have an error from the border router 396 inside the AS, in case the BGP router can not make this 397 determination?] 399 7.2.2. Reachability Aggregation 401 BGP routers aggregate reachability. If the router aggregates 402 reachability that includes the NHRP target, only this router has the 403 visibility to some of the topology changes that can affect the 404 correctness of the route. Therefore, this router is a border router 405 for this NHRP request. 407 It must originate a new request, place the correct information in the 408 request, reeceive the response, and generate the correct response 409 towards the requester. This aggregating router must also monitor 410 routing in case of changes which affect the request. 412 If the router later on receives a Purge message for the NHRP 413 forwarding route, the router treats this event as if there was a 414 change in the NHRP forwarding route (even if the there was no changes 415 in the route). 417 It should be noted that this conditions applies if the router COULD 418 aggregate relevant routing information, even if it currently does 419 not. 421 7.3. Handling NHRP Request at the destination domain border router 423 When a border router receives an NHRP Request from a BGP speaker, and 424 the border router determines that all the destinations covered by the 425 NHRP target of the Request are within the (IGP) domain of that border 426 router, the border router determines the NHRP forwarding route for 427 the NHRP target carried by the Request. The newly formed Request 428 contains exactly the same NHRP target as the received Request; the 429 NHRP IGP Information indicates the IGP this router is using to select 430 the route to the destination. The newly originated Request is sent 431 to the next hop of the NHRP forwarding route. Once the border router 432 receives a Reply to its own Request, the border router uses the next 433 hop information from the Reply to construct its own Reply to the 434 source of the original NHRP Request. 436 If the border router later on receives a Purge message for the NHRP 437 forwarding route, the border router treats this event as if there was 438 a change in the NHRP forwarding route (even if the there was no 439 changes in the route). 441 8. More state, less messages 443 It should be possible to reduce the number of Purge messages and 444 subsequent NHRP messages (caused by the Purge messages) by 445 maintaining more state on the border routers at the source and 446 destination domains, and the BGP routers that perform aggregation 447 along the path from the source to the destination. 449 Specifically, on these routers it would be necessary to keep the 450 information about all the NHRP targets for which the routers maintain 451 the shortcut information. This way when such a router determines 452 that the NHRP forwarding route (for which the router maintains the 453 shortcut information) changes due to some local routing changes, the 454 router could check whether these local changes impact forwarding to 455 the destinations covered by the NHRP targets. Only for the targets 456 that are impacted by the changes the router would send Purge 457 messages. 459 Note that this mechanism (maintaining NHRP targets) precludes the use 460 of Address Prefix Extension - the shortcut will be determined only 461 for the destinations covered by the NHRP target (so, if the target is 462 a single IP address, then the shortcut would be determined only for 463 this address). 465 9. NHRP IGP Information Extension Format 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 0-3 |C|u| Type = 9 | Length = 4 | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 4-7 | flags |b| Reserved | IGP ID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 C "Compulsory." If clear, and the NHS does not recognize the 476 type code, the extension mayb safely be ignored. For the 477 IGP Information extension, this bit is clear. 479 [Discussion. There is a deployment tradeoff against 480 robustness in the setting of the C bit.] 482 u Unused and must be set to zero 484 Type The extension type code. For the IGP Information 485 extension, this is 9. 487 Length the length in octets of the value. For this extension, 488 this is 4. 490 flags Other than the "b" flag, these are reserved, SHALL be set 491 to 0 on transmission, and SHALL be ignored on reception. 493 b This flag indicates whether the request (or a predecessor 494 thereof) was originated by a BGP speaker. Set (to 1) to 495 indicate that the BGP speaker has operated on this. 496 Clear (to 0) if not. 498 IGP ID This field indicates the IGP used by the request 499 originator. The currently defined values are: 501 1 = RIP 502 2 = RIPv2 503 3 = OSPF 504 4 = Dual IS-IS 506 10. Open issues 508 The mechanisms described in this document assume that certain routers 509 along a path taken by an NHRP Request would be required to maintain 510 state associated with the NHRP forwarding route associated with the 511 NHRP target carried by the Request. However, it is quite clear that 512 the router(s) may also lose this state. Further study of the impact 513 of losing the state is needed before advancing the use of NHRP for 514 establishing shortcuts among routers. 516 The mechanisms described in this document may result in a situation 517 where a router would be required to maintain NHRP peering with 518 potentially a fairly large number of other routers. Further study is 519 needed to understand the implications of this on the scalability of 520 the approach where NHRP is used to establish shortcuts among routers. 522 This document doesn't have a proof that the mechanisms described here 523 result in loop-free steady state forwarding when NHRP is used to 524 establish shortcuts among routers. 526 11. Security Considerations 528 Security is provided in the base NHRP protocol, using hop-by-hop 529 authentication. There is no change to the fundemental security 530 capabilities provided therein when these extensions are used. It 531 should be noted that the assumption of transitive trust which is the 532 basis of such security may well be significantly weaker in an inter- 533 domain environment, and administrators of border routers should take 534 this into consideration. 536 12. References 538 [1] J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy., 539 "NBMA Next Hop Resolution Protocol", RFC-2332, USC/Information 540 Sciences Institute, April 1998. 542 [2] D. Cansever., "NHRP Protocol Applicability Statement", RFC-2333, 543 USC/Information Sciences Institute, April 1998 545 [3] S. Bradner., "Key words for use in RFCs to Indicate Requirement 546 Levels", RFC-2119, USC/Information Sciences Institute, March 1997. 548 13. Acknowledgements 550 To be supplied. 552 14. Author Information 554 Joel M. Halpern 555 Newbridge Networks Inc. 556 593 Herndon Parkway 557 Herndon, VA 20170 558 Phone: (703) 736-5954 559 email: jhalpern@newbridge.com 561 Yakov Rekhter 562 cisco Systems, Inc. 563 170 Tasman Dr. 564 San Jose, CA 95134 565 Phone: (914) 528-0090 566 email: yakov@cisco.com