idnits 2.17.00 (12 Aug 2021) /tmp/idnits49657/draft-przygienda-bgp4-atm-00.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 (2022-05-21) 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) 2022 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. == 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. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (19 November 1997) is 8949 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'AF95' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF96b' ** Obsolete normative reference: RFC 1966 (ref. 'Bat96') (Obsoleted by RFC 4456) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ca96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'CH97b' -- Possible downref: Non-RFC (?) normative reference: ref. 'CPS96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Dav97' ** Obsolete normative reference: RFC 1577 (ref. 'Lau94') (Obsoleted by RFC 2225) -- Possible downref: Non-RFC (?) normative reference: ref. 'PD97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'PD97b' ** Obsolete normative reference: RFC 1771 (ref. 'RL95') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'RL97' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Przygienda 2 INTERNET DRAFT Bell Labs, Lucent Technologies 3 19 November 1997 5 BGP-4 over ATM and Proxy PAR 6 8 Status of This Memo 10 This document is an Internet Draft, and can be found as 11 draft-przygienda-bgp4-atm-00.txt in any standard internet drafts 12 repository. Internet Drafts are working documents of the Internet 13 Engineering Task Force (IETF), its Areas, and its Working Groups. 14 Note that other groups may also distribute working documents as 15 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 21 ``working 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 other 25 Internet Draft. 27 Abstract 29 This draft specifes for BGP-4 implementors and users mechanisms 30 describing how the protocol operates in ATM networks over PVC and 31 SVC meshes with the presence of Proxy PAR. These recommendations 32 do not require any protocol changes and allow for simpler, more 33 efficient and cost-effective network designs. Proxy PAR can help to 34 distribute changes of peer relationships when BGP-4 capable routers 35 are reconfigured on the ATM cloud. 37 1. Introduction 39 1.1. Introduction to Proxy PAR 41 Proxy PAR [CPS96, PD97a] is an extension allowing for different ATM 42 attached devices to interact with PAR capable switches and obtain 43 information about non-ATM services without executing PAR [Ca96] 44 which is an extension of PNNI [AF96b] themselves. The client side 45 is much simpler in terms of implementation complexity and memory 46 requirements than a complete PAR protocol stack and should allow for 47 easy implementation in e.g. existing IP routers. Additionally, 48 clients can use Proxy PAR to register different non-ATM services and 49 protocols they support. Proxy PAR has consciously not been included 50 as part of ILMI due to the complexity of PAR information passed in 51 the protocol and the fact that it is intended for integration of 52 non-ATM protocols and services only. A device executing Proxy PAR 53 does not necessarily need to execute ILMI or UNI signaling although 54 this normally will be the case. The context or reference model is 55 aligned with the one included in ILMI [AF96a]. 57 The protocol in itself does not specify how the distributed service 58 registration and data delivered to the client is supposed to be 59 driving other protocols so e.g. OSPF routers finding themselves 60 through proxy PAR could use this information in RFC1577 [Lau94] 61 fashion, forming a full mesh of point-to-point connections to 62 interact with each other to simulate broadcast interfaces. For the 63 same purpose LANE [AF95] or MARS [Arm96] could be used. 65 As a by-product, Proxy PAR could provide the ATM address resolution 66 for IP attached devices but such resolution can be achieved by other 67 protocols under specification in IETF as well, e.g. [CH97a, CH97b]. 68 And last but not least, it should be mentioned here that the 69 protocol coexists with and complements the ongoing work in IETF 70 on server detection via ILMI extensions [Dav97] and opaque LSAs 71 [CH97a, CH97b]. 73 1.1.1. Proxy PAR Scopes 75 Any Proxy PAR registration is carried only within a defined scope 76 that is set during registration and is equivalent to the PNNI routing 77 level. Since no assumptions except scope values can be made about 78 the information distributed (e.g. IP addresses bound to NSAPs 79 are not assumed to be aligned with them in any respect such as 80 encapsulation or functional mapping), registration information cannot 81 be summarized. This makes a careful handling of scopes necessary to 82 preserve the scalability. More detailed comments on these issues and 83 optimizations possible when logical IP topology aligns with aspects 84 of ATM topology can be found in [PD97b]. 86 1.2. Introduction to BGP 88 Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) 89 and described in [RL95, RL97] from which most of the following 90 paragraphs have been taken almost literally. 92 The primary function of a BGP speaking system is to exchange 93 network reachability information with other BGP systems. This 94 network reachability information includes information on the 95 list of Autonomous Systems (ASs) that reachability information 96 traverses. This information is sufficient to construct a graph of AS 97 connectivity from which routing loops may be pruned and some policy 98 decisions at the AS level may be enforced. 100 BGP runs over a reliable transport protocol. This eliminates the 101 need to implement explicit update fragmentation, retransmission, 102 acknowledgment, and sequencing. Any authentication scheme used 103 by the transport protocol may be used in addition to BGP's own 104 authentication mechanisms. The error notification mechanism used 105 in BGP assumes that the transport protocol supports a "graceful" 106 close, i.e., that all outstanding data will be delivered before the 107 connection is closed. 109 BGP deployments are normally configured such that that all BGP 110 speakers within a single AS must be fully meshed so that any external 111 routing information must be re-distributed to all other routers 112 within that AS. This represents a serious scaling problem that 113 has been well documented with several alternatives proposed. The 114 alternative supported in Proxy PAR are route reflectors [Bat96] due 115 to their simplicity, easy migration and compatibility with existing 116 BGP configurations. 118 2. BGP over ATM 120 2.1. Model 122 The model used for BGP operation over ATM in connection with 123 Proxy PAR assumes that not only pre-configured peers exist but 124 neighbor relationships can be formed dynamically based on discovery 125 mechanisms. Such a discovery must be provided by an underlying 126 layer since BGP does not include peer auto-detection that would be 127 comparable with e.g. OSPF's hellos used to find all OSPF routers on 128 a specific subnet. To fulfill this purpose, Proxy PAR allows BGP to 129 register and query the following data with the server: 131 - ATM address 133 - IP instance 135 - IP address 137 - IP mask 139 - BGP Identifier 141 - route reflector type as one of: 143 * reflector of a certain cluster or 145 * client of a certain cluster or 147 * non-client 149 The motivation of such a model is to allow for a simpler maintainance 150 of BGP router configuration when some router interfaces are connected 151 over ATM. As an example, full mesh connectivity on a specific 152 subnet does not require the configuration of peer relationsships in 153 routersa priori but a router can register as providing BGP services 154 on an interface and his possible peers discover it through Proxy 155 PAR queries. Figure 1 illustrates a possible BGP scenario with 156 several cases of relationsships based on the following Proxy PAR 157 registrations: 159 - Router R1 is configured to be BGP capable and has the interface 161 * 1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255 162 +--+ 163 |R1| 164 +--+ 165 1.1.1.1 | register BGP for 166 | AS101, BGP Id 1.1.1.1, no route 167 | reflector 168 | 169 ======================= | ========================== AS101 170 1.1.1/255.255.255.0 | 171 +--------------+---------+-------------+------+ DMZ 172 | | 173 ============= | ===================== | ============ AS100 174 | | 175 | 1.1.1.3 | 1.1.1.2 176 | | 177 +--+ +--+ 178 |R2| registers BGP for |R3| registers BGP for 179 | | AS100, Id 1.1.1.3, | | AS100, Id 1.1.1.2, 180 +--+ non-client +--+ RR for cluster 4 181 | | 182 | 1.1.2.3 | 1.1.2.2 183 | | 184 +---+----------+-----------------------+-----------+ 185 | 1.1.2/255.255.255.0 186 | 187 | 1.1.2.1 + 188 +--+ | 189 |R4|-----------+ 190 +--+ 1.1.3.1 | 1.1.3.2 +--+ registers BGP for AS100, 191 +-----------|R5| Id 1.1.2.1, 192 | +--+ RR client cluster 4 193 + 195 Figure 1: Logical IP Topology with Proxy PAR Registrations (Single ATM 196 network) 198 - Router R3 is configured to be BGP capable, is route reflector for 199 cluster id 4, and has the interfaces 201 * 1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and 203 * 1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS 205 - Router R2 is configured to be BGP capable and has the interfaces 207 * 1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and 209 * 1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS 211 - Router R5 is configured to be BGP capable, is a client of route 212 reflector cluster id 4, and has the interface 214 * 1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS 216 It has to be stated here that the model assumes that E-BGP-multihop 217 will not be supported through auto-configuration. Based on such an 218 assumption, the following queries are generated by the routers and 219 conclusions drawn concerning the BGP sessions to be formed: 221 Q1> Router R1 queries for all BGP capable routers on the DMZ 222 subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3 223 and 1.1.1.2 and being in a different AS. Router R1 concludes to 225 * build a E-BGP connection to router R3 (shown with &'s in 226 Figure 2) 228 * build a EBPG connection to router R2 (shown with #'s in 229 Figure 2) 231 Q2> Router R2 queries for all BGP capable routers on the DMZ subnet 232 and discovers R3 and R1 on the same subnet and concludes to 234 * build a E-BGP connection to router R1 since it is in a 235 different AS 237 * not to build a E-BGP connection to router R3 since it is in 238 the same AS 240 Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions 241 analogous to Q2> 243 Q4> Router R2 queries for all routers supporting BGP inside of the 244 same AS, detects R3 and R5 and concludes to 246 ___________________________________________ 247 1. since one of its interfaces is on this subnet 248 +--+ 249 |R1| 250 +--+ 251 1.1.1.1 #& 252 #& 253 #& 254 #& 255 ======================= #& ========================= AS101 256 #& 257 +--------------###########&&&&&&&&&&&&&&------+ DMZ 258 # & 259 ============= # ===================== & ============ AS100 260 # & 261 # 1.1.1.3 & 1.1.1.2 262 # & 263 +--+ +--+ 264 |R2| |R3| 265 | | | | 266 +--+ +--+ 267 % %@ 268 % 1.1.2.3 %@ 1.1.2.2 269 % %@ 270 % %@ 271 +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+ 272 @@@@@@@@@@@@@@@@@@@@@@@@@@ 273 @ 274 @ + 275 +-@@ | 276 |R4@@@@@@@@@@@@@ 277 +--+ @ 1.1.3.2 +--+ 278 @@@@@@@@@@@@|R5| 279 + +--+ 281 Figure 2: Active BGP Connections after Auto-Discovery in Figure 1. 283 * build an I-BGP connection to R3 since R3 is a reflector and 284 R2 is a non-client (shown with %'s in Figure 2) 286 * not build an I-BGP connection to R5 since R5 is a client of a 287 route reflector 289 Q5> Router R3 queries for all routers supporting BGP inside of the 290 same AS, detects R2 and R5 and concludes to 292 * build an I-BGP connection to R2 since R3 is a reflector and 293 R2 is a non-client 295 * build an I-BGP connection to R5 since R5 is a client of the 296 route reflector for the same cluster (shown with @'s in 297 Figure 2) 299 Q6> Router R5 queries for all routers supporting BGP inside of the 300 same AS, detects R2 and R3 and concludes to 302 * not build an I-BGP connection to R2 since R5 is a reflector 303 client and R2 is a non-client 305 * to build an I-BGP connection to R3 since R3 is the reflector 306 for the same cluster R5 is client of 308 The resulting peerings are visualized in Figure 2. Based on the 309 configuration of BGP properties the network automatically set up 310 valid and necessary connections between routers. It should be 311 obvious that especially for I-BGP such a mechanism faciliates the 312 maintainance of many routers inside of an AS. The necessary route 313 reflector and mesh connections for BGP are built correctly. A 314 carefull reader observes as well that the automatically formed full 315 set of E-BGP connections between AS border routers is not always a 316 good thing. This problem will be given some special consideration. 318 The intended auto-configuration behavior when registering and 319 retrieving information can be split across the internal and external 320 BGP functionality boundary. Since I-BGP requires a full mesh 321 configuration (2) Proxy PAR information proves very beneficial to 322 meet this necessary constraint in an automatic manner. For E-BGP, as 323 mentioned above, a full mesh between all peers on the same subnet is 324 not always a good solution and therefore Proxy PAR information has to 325 be treated more carefully or not used at all. 327 ___________________________________________ 328 2. with exceptions in presence of route reflectors, of course 329 2.2. BGP Configuration Interaction with Proxy PAR 331 To resolve problems with multiple IP subnets operating on top of a 332 single ATM NSAP, multiple BGP instances, and possibly even multiple 333 ATM clouds the router attaches to, router configuration has to define 334 what information is feasible to be registered. As default, any 335 new upcoming IP interface running on top of an ATM link should be 336 registered with the server on one of the ATM links interfacing with 337 the same ATM cloud. The necessary IP instance is determined by 338 the BGP instance and the NSAP is equivalent to the NSAP of the ATM 339 interface through which the registration is performed. 341 2.2.1. Registration of Information for Autoconfiguration of External BGP 342 Peerings 344 An implicit assumption when using Proxy PAR for autoconfiguration of 345 BGP external peerings is that multihop peers are not supported. A 346 BGP router with an IP over ATM interface that attaches to a subnet 347 between different AS'es registers the interface for the according IP 348 instance with one of the proxy PAR servers on the same cloud. It is 349 possible, although not necessary, to omit multiple registrations in 350 the case of a BGP router having multiple interfaces to the same IP 351 subnet with broadcast capabilities. 353 2.2.2. Registration of Information for Autoconfiguration of Internal BGP 354 Peerings 356 For the IP over ATM interfaces on subnets being entirely inside of 357 the router's AS, BGP instances should register with proxy PAR server. 358 This allows for necessary sessions to be formed and consecutively 359 provides full mesh connectivity between non-clients, and star 360 connectivity inside route reflector clusters. Same optimizations as 361 described in section 2.2.1 are possible. 363 2.3. Proxy PAR Interaction with BGP Configuration 365 2.3.1. Autoconfiguration of Internal BGP Peerings 367 Proxy PAR presence in a BGP network 'on the internal side' is helping 368 to meet the requirement that all I-BGP peers have to be connected as 369 full-mesh or connect to their route reflectors. To make sure that 370 all route reflector clients and non-clients are configured correctly, 371 Proxy PAR queries will present enough information to let the routers 372 configure a minimal valid connectivity graph. After being provided 373 with the information about all BGP peers running in the same AS, a 374 BGP router determines which peers it must initiate connections to 375 based on the following criteria: 377 - looking at the other router's BGP identifier no session has been 378 formed yet and 380 - the other router is in the same AS and 382 * one router is route reflector with the same cluster ID and 383 the other router is a client of this cluster or 385 * one of the routers is a non-client 387 The example in section 2.1 encompasses the different cases that can 388 trigger initiation of connections. 390 2.3.2. Autoconfiguration of external BGP peerings 392 Proxy PAR registration information made available can be used to 393 determine which BGP routers are present to form sessions with. 394 Normally, all routers on a specific DMZ subnet are interested in 395 forming relationships with routers in different ASes to exchange 396 route information. However, to prevent unnecessary or insecure 397 external sessions, each of the IP interfaces on a subnet reaching 398 into other AS'es can filter information from query results based 399 on any of the fields or combinations thereof. The filter would 400 prevent BGP from autodetecting the registration and effectively the 401 possible neighbor. Since the connection could be initiated from 402 either side, the filters should be symmetrical in both BGP peers that 403 try to prevent that session from forming. If this is unenforcable, 404 a peer accepting an E-BGP connection for which Proxy PAR information 405 is filtered, could explicitly close it after providing appropriate 406 notification. 408 2.4. IP to ATM Address Resolution 410 Given the nature of Proxy PAR registrations that contain not only 411 BGP specific information but always carry IP interface address and 412 the attached NSAP, when running BGP over IP interfaces on top of ATM 413 with Proxy PAR capabilities, the information obtained in queries can 414 be used to provide address resolution for the lower layers. When 415 BGP chooses to initiate a connection to a peer, lower layers of the 416 TCP/IP protocol stack could use the available Proxy PAR information 417 to resolve the IP address into the necessary NSAP of the registration 418 point. Such a solution however necessitates an appropriate stack 419 architecture. 421 3. Acknowledgments 423 Comments and contributions from several sources, especially Rob 424 Coltun are included in this work. 426 4. Security Consideration 428 Security issues in the context of BGP autoconfiguration in presence 429 of Proxy PAR can be split into parts specific to either of the 430 protocols. BGP protocol addresses the issues in existing RFCs 431 and ongoing work. PNNI protocol in version 2 contains peer 432 authentication mechanisms and Proxy PAR in itself could be extended 433 to encompass the same security features in the future. To address 434 the problem of security of Proxy PAR client/server interactions, 435 especially registrations that could be used for denial-of-service 436 attacks is an issue not addressed so far. Its scope is similar to 437 the problem of a secure ILMI [AF96a]. 439 5. Conclusions 441 This RFC specifes for BGP implementors and users mechanisms 442 describing how the protocol operates in ATM networks over PVC and 443 SVC meshes with the presence of Proxy PAR. These recommendations 444 do not require any protocol changes and allow for simpler, more 445 efficient and cost- effective network designs. Proxy PAR can help 446 to distribute configuration changes when BGP capable routers are 447 reconfigured on the ATM cloud and greatly facilitates consistence of 448 I-BGP meshes and can be used for E-BGP auto-configuration as well. 450 References 452 [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum 453 af-lane-0021.000, January 1995. 455 [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) 456 Specification 4.0. ATM Forum 95-0417R8, June 1996. 458 [AF96b] ATM-Forum. Private Network-Network Interface Specification 459 Version 1.0. ATM Forum af-pnni-0055.000, March 1996. 461 [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based 462 ATM Networks, RFC 2022. Internet Engineering Task Force, 463 November 1996. 465 [Bat96] T. Bates. BGP Route Reflection, RFC 1966. Internet 466 Engineering Task Force, June 1996. 468 [Ca96] R. Callon and al. An Overview of PNNI Augmented Routing. 469 ATM Forum 96-0354, April 1996. 471 [CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet 472 Draft, 1997. 474 [CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution 475 Advertisement Option. Internet Draft, 1997. 477 [CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI 478 Augmented Routing. ATM Forum 96-0838, June 1996. 480 [Dav97] M. Davison. Simple ILMI-Based Server Discovery. Internet 481 Draft, 1997. 483 [Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577. 484 Internet Engineering Task Force, January 1994. 486 [PD97a] T. Przygienda and P. Droz. Proxy PAR. ATM Forum 97-0495, 487 97-0705, 97-0882, July 1997. 489 [PD97b] T. Przygienda and P. Droz. Proxy PAR. Internet Draft, 1997. 491 [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), 492 RFC 1771. Internet Engineering Task Force, March 1995. 494 [RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). 495 Internet Draft, 1997. 497 Authors' Addresses 499 Tony Przygienda 500 Bell Labs, Lucent Technologies 501 101 Crawfords Corner Road 502 Holmdel, NJ 07733-3030 503 prz@dnrc.bell-labs.com