RFC 4277
Experience with the BGP-4 Protocol
Title Block 🎀
Okay bestie, this is RFC 4277: Experience with the BGP-4 Protocol 🌸 It's an Informational doc (so it gives info to the Internet community, not a standard) by D. McPherson of Arbor Networks and K. Patel of Cisco Systems, dated January 2006. The title block doesn't list anything it obsoletes or updates, so this one's a solo vibe 🦋
Status of This Memo 💅
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ⭐
Copyright (C) The Internet Society (2006).
Abstract 🧚
The whole point of this memo is to document how a routing protocol got through the requirements for publication as an Internet Draft Standard, and how BGP version 4 (BGP-4) did it 👑
This report covers the "the second report" requirement from Section 6.0 of RFC 1264 🫶 To pull that off, it augments RFC 1773 and shares what people learned between when the protocol became a Draft Standard and when it was submitted for Standard 💜
Table of Contents 🍓
1. Introduction ................................................. 3
2. BGP-4 Overview ............................................... 3
2.1. A Border Gateway Protocol .............................. 3
3. Management Information Base (MIB) ............................ 3
4. Implementation Information ................................... 4
5. Operational Experience ....................................... 4
6. TCP Awareness ................................................ 5
7. Metrics ...................................................... 5
7.1. MULTI_EXIT_DISC (MED) .................................. 5
7.1.1. MEDs and Potatoes .............................. 6
7.1.2. Sending MEDs to BGP Peers ...................... 7
7.1.3. MED of Zero Versus No MED ...................... 7
7.1.4. MEDs and Temporal Route Selection .............. 7
8. Local Preference ............................................. 8
9. Internal BGP In Large Autonomous Systems ..................... 9
10. Internet Dynamics ............................................ 9
11. BGP Routing Information Bases (RIBs) ......................... 10
12. Update Packing ............................................... 10
13. Limit Rate Updates ........................................... 11
13.1. Consideration of TCP Characteristics ................... 11
14. Ordering of Path Attributes .................................. 12
15. AS_SET Sorting ............................................... 12
16. Control Over Version Negotiation ............................. 13
17. Security Considerations ...................................... 13
17.1. TCP MD5 Signature Option ............................... 13
17.2. BGP Over IPsec ......................................... 14
17.3. Miscellaneous .......................................... 14
18. PTOMAINE and GROW ............................................ 14
19. Internet Routing Registries (IRRs) ........................... 15
20. Regional Internet Registries (RIRs) and IRRs, A Bit
of History ................................................... 15
21. Acknowledgements ............................................. 16
22. References ................................................... 17
22.1. Normative References ................................... 17
22.2. Informative References ................................. 171. Introduction ✨
Okay so the purpose here is the same as the abstract: documenting how BGP-4 satisfied the requirements for a routing protocol to be published as an Internet Draft Standard 💖
This report covers "the second report" requirement, described in Section 6.0 of [RFC1264] 🎀 To fulfill it, this report augments [RFC1773] and describes extra knowledge and understanding gained between when the protocol became a Draft Standard and when it was submitted for Standard 🦋
2. BGP-4 Overview 🌈
BGP is an inter-autonomous system routing protocol made for TCP/IP internets 🌸 The main job of a BGP speaking system is to swap network reachability information with other BGP systems. That info includes the list of Autonomous Systems (ASes) that the reachability information goes through 🧚 Honestly, that's enough to build a graph of AS connectivity, which lets you prune routing loops and enforce some policy decisions at the AS level 👑
The first BGP version was published in [RFC1105]. After that came BGP Versions 2, 3, and 4, specified in [RFC1163], [RFC1267], and [RFC1771], in that order 💜 Changes to BGP-4 after it went to Draft Standard [RFC1771] are listed in Appendix N of [RFC4271] ✨
2.1. A Border Gateway Protocol 🫶
Same tea as above: the initial version was published in [RFC1105]. BGP version 2 is defined in [RFC1163]. BGP version 3 is defined in [RFC1267]. BGP version 4 is defined in [RFC1771] and [RFC4271]. Appendices A, B, C, and D of [RFC4271] give summaries of the changes between each iteration of the BGP specification 🍓
3. Management Information Base (MIB) 🔥
The BGP-4 Management Information Base (MIB) has been published [BGP-MIB]. It was updated from earlier versions, which are documented in [RFC1657] and [RFC1269], respectively 💅
Apart from a few system variables, the BGP MIB is split into two tables: the BGP Peer Table and the BGP Received Path Attribute Table 🧚
The Peer Table shows info about BGP peer connections, like their state and current activity. The Received Path Attribute Table holds all the attributes received from all peers before local routing policy gets applied. The attributes actually used to decide a route are only a subset of that received table 👑
4. Implementation Information 🌸
There are lots of independent, interoperable BGP implementations available right now 🦋 The previous version of this report gave an overview of the implementations used in the operational Internet, but it was suggested that a separate BGP Implementation Report [RFC4276] be made instead 💖
Implementation experience with Cisco's BGP-4 implementation was documented as part of [RFC1656] 🎀
For all the extra implementation info, check [RFC4276] 🫶
5. Operational Experience 🌈
This section talks about operational experience with BGP and BGP-4 ✨
BGP has been used in production since 1989, and BGP-4 since 1993 💅 Production use includes all the significant features of the protocol 🔥 The current production environment, where BGP is the inter-autonomous system routing protocol, is super heterogeneous. Link bandwidth ranges from 56 Kbps to 10 Gbps 🧚 The routers running BGP range from relatively slow, general purpose CPUs to very high performance RISC network processors. That includes both special purpose routers and general purpose workstations running various UNIX derivatives and other operating systems 👑
Topologies vary too, from very sparse to pretty dense 💜 The old requirement for full-mesh IBGP topologies has mostly been fixed by BGP Route Reflection, Autonomous System Confederations for BGP, and often a mix of the two 🍓 BGP Route Reflection was first defined in [RFC1966] and updated in [RFC2796]. Autonomous System Confederations for BGP were first defined in [RFC1965] and updated in [RFC3065] ✨
At the time of writing, BGP-4 is used as the inter-autonomous system routing protocol between all Internet-attached autonomous systems, with nearly 21k active autonomous systems in the global Internet routing table 🎀
BGP handles both exchanges of routing information between a transit and a stub autonomous system, and between multiple transit autonomous systems 🦋 There's no protocol distinction between sites that were historically called "backbones" and "regional" or "edge" networks 🫶
The full set of exterior routes carried by BGP is well over 170,000 aggregate entries, which stands for several times that many connected networks 🔥 Some service provider core routers have more than 2.5 million active paths 💀 Native AS path lengths go up to 10 for some routes, and "padded" path lengths of 25 or more autonomous systems exist too 😭
6. TCP Awareness 🧚
BGP uses TCP [RFC793] as its Transport Layer protocol 💖 So all the characteristics inherent to TCP get inherited by BGP 💅
For example, because of how TCP behaves, bandwidth capabilities might not get realized, thanks to TCP's slow start algorithms and slow-start restarts of connections, etc. 🙈
7. Metrics 💜
This section talks about the different metrics used within the BGP protocol 🌈 BGP has a separate metric parameter for IBGP and EBGP ✨ That lets policy-based metrics override the distance-based metrics, so each autonomous system can define its own independent policies, both Intra-AS and Inter-AS 👑 The BGP Multi Exit Discriminator (MED) gets used as a metric by EBGP peers (aka inter-domain), while Local Preference (LOCAL_PREF) is used by IBGP peers (aka intra-domain) 🫶
7.1. MULTI_EXIT_DISC (MED) 💖
okay so BGP version 4 took the old INTER-AS metric and renamed it a MULTI_EXIT_DISC (MED) 🎀 It's a value that can be used in the tie-breaking step when picking a preferred path to a given address space. It also lets BGP speakers tell a peer AS what the best entry point into the local AS is 🦋
The MED was supposed to only be used when comparing paths learned from different external peers in the same AS. But lots of implementations let you compare MEDs between different autonomous systems too 👀
That can seem like a fine idea in some setups, but you have to be careful when you compare MEDs across autonomous systems 💅 BGP speakers often work out their MED values from the IGP metric to reach a given BGP NEXT_HOP inside the local AS. This means MEDs can nicely reflect the IGP topology when routes get advertised to peers ✨ That's fine when you're comparing MEDs from a single adjacent AS, but it can lead to really bad decisions when you compare MEDs from different autonomous systems. This is most likely when the autonomous systems use different ways of deriving IGP metrics and BGP MEDs, or even run different IGP protocols with wildly different metric spaces 😭
Another MED thing to think about is how aggregating BGP routing information affects MEDs. Aggregates are often generated from several places in an AS for stability, redundancy, and other network design goals 🌈 If the MEDs are derived from IGP metrics tied to those aggregates, the MED value advertised to peers can end up giving really suboptimal routing 💀
The MED was purposely designed to be a "weak" metric that only gets used late in the best-path decision process 🍓 The BGP working group was worried that any metric set by a remote operator would only change routing in a local AS if no other preference had been specified. One of the main goals of the MED design was to make sure peers couldn't "shed" or "absorb" traffic for the networks they advertise 🙅♀️
7.1.1. MEDs and Potatoes 🥔
Picture traffic flowing between a pair of destinations. Each one is connected to two transit networks, and each transit network gets to choose between two options. It can send the traffic to the peering point closest to the other transit provider, or it can pass the traffic to the peering point that advertises the least cost through the other provider 🌸 The first option is called "hot potato routing" because, like a hot potato in your bare hands, whoever's holding it tries to get rid of it fast 🔥 Hot potato routing happens by not passing the EBGP-learned MED into the IBGP. This keeps transit traffic low for the provider routing it. The much rarer option is "cold potato routing", where the transit provider spends its own transit capacity to carry the traffic to the point in the adjacent transit provider's network that's advertised as closest to the destination 🧊 Cold potato routing happens by passing the EBGP-learned MED into IBGP.
If one transit provider uses hot potato routing and another uses cold potato routing, the traffic between the two tends to be symmetric ✨ Depending on the business relationships, if one provider has more capacity or a much less congested transit network, it might use cold potato routing. The NSF-funded NSFNET backbone and NSF-funded regional networks were widespread examples of cold potato routing in the mid 1990s 🎀
Sometimes a provider uses hot potato routing for some destinations toward a given peer AS and cold potato routing for others. The way commercial and research traffic was handled on NSFNET in the mid 1990s is an example of this 🙈 Honestly though, this is better described as 'mashed potato routing', a name that reflects how complicated the router configurations were back then 🥹
There are also more intuitive names that fall outside the vegetable kingdom 🌈 Cold potato routing can be called "best exit routing", and hot potato routing can be called "closest exit routing" 💜
7.1.2. Sending MEDs to BGP Peers 📨
[RFC4271] lets MEDs received from any EBGP peers by a BGP speaker be passed to its IBGP peers. Advertising MEDs to IBGP peers isn't a required behavior, but it's a common default 💅 MEDs that a BGP speaker receives from EBGP peers SHOULD NOT be sent to other EBGP peers 🚫
Many implementations also have a way to derive MED values from IGP metrics. That lets the BGP MED info reflect the IGP topology and metrics of the network when it gets passed on to adjacent autonomous systems 🦋
7.1.3. MED of Zero Versus No MED 0️⃣
[RFC4271] requires an implementation to provide a mechanism that lets the MED be removed 🧹 Before that, implementations didn't treat a missing MED value the same as a MED of zero. [RFC4271] now requires that no MED value be equal to zero 🙌
Many implementations can explicitly set a missing MED value to "worst", meaning less preferable than zero or any larger value 💀
7.1.4. MEDs and Temporal Route Selection ⏳
Some implementations have hooks that apply temporal behavior in MED-based best path selection. So when everything is equal up to MED consideration, preference goes to the "oldest" path, without preferring the lower MED value 👴 The reasoning is that "older" paths are presumably more stable, so they're more preferable 🧓 However, temporal behavior in route selection gives non-deterministic behavior, and that often makes it undesirable 😤
8. Local Preference 👑
The LOCAL_PREF attribute was added so a network operator can easily set up a policy that overrides the standard best path determination mechanism, without separately configuring local preference policy on each router 🎀
One shortcoming of the BGP-4 specification was the suggestion that a default value of LOCAL_PREF be assumed if none was provided. Defaults of zero or the maximum value each have range limitations 🙃 A common default would help multi-vendor routers interoperate in the same AS. (Since LOCAL_PREF is a local administration attribute, there's no interoperability drawback across AS boundaries 🫶)
[RFC4271] requires that LOCAL_PREF be sent to IBGP Peers and not to EBGP Peers ✨ No default value for LOCAL_PREF is defined, though the common default value is 100 💯
Another area that still needs exploring is a method that lets an originating AS influence the best path selection process 🧭 For example, a dual-connected site might pick one AS as its primary transit service provider and another as its backup 🍼
/---- transit B ----\
end-customer transit A----
/---- transit C ----\When both transit service providers connect to a third provider, the real decision is made by that third provider 😬 There's no mechanism to indicate a preference if the third provider wants to respect it.
One general-purpose suggestion has been to carry an optional vector, matching the AS_PATH, where each transit AS can indicate a preference value for a given route 🌟 Cooperating autonomous systems could then pick traffic based on comparing the "interesting" portions of this vector, according to routing policy 🧩
Protecting a given autonomous system's routing policy is a top priority, but avoiding extensive hand configuration of routing policies needs a closer look in future BGP-like protocols 🥰
9. Internal BGP In Large Autonomous Systems 🌸
This isn't strictly a protocol issue, but network operators who maintain autonomous systems with a large number of peers have raised another concern 🫣 Each speaker peering with an external router is responsible for propagating reachability and path information to all other transit and border routers within that AS. This is typically done by setting up internal BGP connections to all transit and border routers in the local AS 🕸️
The number of BGP peers that can be fully meshed depends on a bunch of factors, including the number of prefixes in the routing system, the number of unique paths, the stability of the system, and, maybe most importantly, implementation efficiency ⚡ So even though it's hard to define "a large number of peers", there's always some practical limit 🙃
In a large AS, this leads to a full mesh of TCP connections (n * (n-1)) plus some method of configuring and maintaining those connections 😵💫 BGP doesn't specify how this information should be propagated. So alternatives, like injecting BGP routing information into the local IGP, have been tried, but they turned out to be non-practical (to say the least) 🙅♀️
To ease the need for "full mesh" IBGP, several alternatives have been defined, including BGP Route Reflection [RFC2796] and AS Confederations for BGP [RFC3065] 🦋
10. Internet Dynamics 🦋
As discussed in [RFC4274], the big driver of CPU and bandwidth usage is how dynamic routing is on the Internet 📈 As the Internet has grown, the number of route changes per second has gone up too 😩
We automatically get some damping when more specific NLRI gets aggregated into larger blocks, but that's not enough 🙈 Appendix F of [RFC4271] describes damping techniques that should be applied to advertisements. In future specifications of BGP-like protocols, damping methods should be considered for mandatory inclusion in compliant implementations 🧐
BGP Route Flap Damping is defined in [RFC2439]. It's a mechanism that helps cut down on the amount of routing information passed between BGP peers, which lowers the load on those peers without hurting route convergence time for relatively stable routes 🌈
None of the current implementations of BGP Route Flap Damping store route history by unique NRLI or AS Path, even though RFC 2439 lists this as mandatory 😤 If each AS Path isn't considered separately, you can get overly aggressive suppression of destinations in a densely meshed network. The most severe result is a destination getting suppressed after a single failure 💀 Because the top tier autonomous systems on the Internet are densely meshed, these bad effects are being observed 👀
Route changes are announced using BGP UPDATE messages. The biggest overhead in advertising UPDATE messages happens when the route changes being announced are packed inefficiently 📦 Announcing routing changes that share common attributes in a single BGP UPDATE message saves a lot of bandwidth and cuts processing overhead, as discussed in Section 12, Update Packing 💜
Persistent BGP errors can make BGP peers flap persistently if peer dampening isn't implemented, which can eat a ton of CPU 🔥 Implementors may find it useful to implement peer dampening to avoid that persistent peer flapping [RFC4271] 🫶
11. BGP Routing Information Bases (RIBs) 🎀
okay so [RFC4271] says "Any local policy which results in routes being added to an Adj-RIB-Out without also being added to the local BGP speaker's forwarding table, is outside the scope of this document" 📜
BUT ngl, several well-known implementations don't actually check that Loc-RIB entries were used to fill the forwarding table before installing them in the Adj-RIB-Out 😬 The most common version of this is when a bunch of protocols offer routes for the same prefix, and the preference for the BGP-learned route is lower than another protocol's. So the route learned from the other protocol is the one that gets used to fill the forwarding table 🙈
It may be desirable for an implementation to provide a knob that permits advertisement of "inactive" BGP routes ⚙️
It may be also desirable for an implementation to provide a knob that allows a BGP speaker to advertise BGP routes that were not selected in the decision process 🧠
12. Update Packing 📦
Multiple unfeasible routes can be advertised in a single BGP Update message ✨ And one or more feasible routes can be advertised in a single Update message too, as long as all the prefixes share a common attribute set 💅
BGP4 lets you advertise multiple prefixes with a common set of path attributes in a single update message. This is commonly called "update packing" 🎁 When possible, update packing is recommended, because it's more efficient in a few areas:
- Reduction in system overhead due to generation or receipt of fewer Update messages.
- Reduction in network overhead as a result of less packets and lower bandwidth consumption.
- Reduction in frequency of processing path attributes and looking for matching sets in the
AS_PATHdatabase (if you have one). Consistent ordering of the path attributes allows for ease of matching in the database, as different representations of the same data do not exist.
The BGP protocol suggests that withdrawal information should be packed at the beginning of an Update message, followed by information about reachable routes in a single UPDATE message 🫶 This helps alleviate excessive route flapping in BGP 🌊
13. Limit Rate Updates 🚦
The BGP protocol has different mechanisms to rate limit Update advertisement ⏱️ One of them is the MinRouteAdvertisementInterval parameter, which sets the minimum time that must elapse between advertising routes to a particular destination from a single BGP speaker. This value is set on a per-BGP-peer basis 💜
Because BGP relies on TCP as its Transport protocol, TCP can stop data from being sent when windows are empty 🪟 So multiple updates may end up spaced closer together than they were originally queued. It's not common, but implementations should be aware of this happening 👀
13.1. Consideration of TCP Characteristics 🌸
okay so if a TCP receiver is processing input more slowly than the sender, or the TCP connection rate is the limiting factor, the TCP sending application feels a form of backpressure 😤 When the TCP buffer fills up, the sending application will either block on the write or get an error on the write. In early or naive new implementations, setting options to block on writes or setting options for non-blocking writes are common mistakes, and those implementations treat full-buffer errors as fatal 💀
Once you know full write buffers are expected, there are more pitfalls 🙃 The application should not try to store the TCP stream within the application itself. If the receiver or the TCP connection is persistently slow, the buffer can grow until memory is exhausted 😱 A BGP implementation is required to send changes to all peers for which the TCP connection is not blocked, and it is required to send those changes to the remaining peers when the connection becomes unblocked 🔓
If the preferred route for a given NLRI changes multiple times while writes to one or more peers are blocked, only the most recent best route needs to be sent. That's how BGP is work conserving [RFC4274] 🧘♀️ When there's extremely high route change, a higher volume of route change goes to the peers that can process it faster, and a lower volume goes to the peers that can't keep up 🏃♀️
For implementations that handle differing peer capacities to absorb route change well: if most of the route change comes from a subset of unstable NRLI, the only impact on relatively stable NRLI that makes an isolated route change is slower convergence. And convergence time stays bounded, no matter how much instability there is 💖
14. Ordering of Path Attributes 🗂️
The BGP protocol suggests that BGP speakers sending multiple prefixes per UPDATE message sort and order path attributes according to Type Codes 🔢 This helps their peers quickly spot sets of attributes from different update messages that are semantically different 🔍
Implementers may find it useful to order path attributes according to Type Code, so sets of attributes with identical semantics can be identified more quickly ⚡
15. AS_SET Sorting 🔤
AS_SETs are commonly used in BGP route aggregation 🧩 They shrink the size of AS_PATH information by listing AS numbers only once, no matter how many times they show up during aggregation 📉 AS_SETs are usually sorted in increasing order so AS numbers inside them can be looked up efficiently 🔎 This optimization is optional 🤷♀️
16. Control Over Version Negotiation 🔀
Pre-BGP-4 route aggregation can't be supported by earlier versions of BGP, so an implementation that supports versions in addition to BGP-4 should provide version support on a per-peer basis 🧑🤝🧑 At the time of this writing, all BGP speakers on the Internet are thought to be running BGP version 4 🌐
17. Security Considerations 🛡️😭
Okay this section is SERIOUS bestie 🚨 BGP provides a flexible and extendable mechanism for authentication and security. The mechanism supports schemes with different degrees of complexity 🔐 BGP sessions are authenticated based on the IP address of a peer, and all BGP sessions are also authenticated based on the autonomous system number advertised by a peer 🪪
Because BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP 🧱
17.1. TCP MD5 Signature Option 🔑
[RFC2385] defines a way for the TCP MD5 signature option to validate information transmitted between two peers. This method stops a third party from injecting information (like a TCP Reset) into the datastream, or from modifying the routing information carried between two BGP peers 🙅♀️
At the moment, TCP MD5 is not everywhere, especially in inter-domain scenarios, mostly because of key distribution issues 😮💨 Most key distribution mechanisms are considered too "heavy" at this point 🏋️♀️
Many people naively assumed that an attacker must correctly guess the exact TCP sequence number (along with the source and destination ports and IP addresses) to inject a data segment or reset a TCP transport connection between two BGP peers 🙄 But recent observation and open discussion show that the malicious data only needs to fall within the TCP receive window, which may be quite large. That significantly lowers the complexity of such an attack 🚨
So it is recommended that the MD5 TCP Signature Option be employed to protect BGP from session resets and malicious data injection 🛡️💅
17.2. BGP Over IPsec 🔒
BGP can run over IPsec, either in a tunnel or in transport mode, where the TCP portion of the IP packet is encrypted 🌀 This not only prevents random insertion of information into the data stream between two BGP peers, but also stops an attacker from learning the data being exchanged between the peers 🙈
IPsec does offer several options for exchanging session keys, which may be useful on inter-domain configurations 🗝️ These options are being explored in many deployments, though no definitive solution has been reached on key exchange for BGP in IPsec 🤔
Because BGP runs over TCP and IP, it should be noted that BGP is vulnerable to the same denial of service and authentication attacks that are present in any TCP based protocol 😵💫
17.3. Miscellaneous 🗃️
Another routing protocol issue is providing evidence of the validity and authority of routing information carried within the routing system 🧐 This is currently the focus of several efforts, including efforts to define threats that can be used against this routing information in BGP [BGPATTACK], and efforts to develop a means of providing validation and authority for routing information carried within BGP [SBGP] [soBGP] 🕵️♀️
The Routing Protocol Security Requirements (RPSEC) working group has also been chartered, within the Routing Area of the IETF, to discuss and help address issues surrounding routing protocol security 🧑💻 Within RPSEC, this work is intended to result in feedback to BGP4 and future protocol enhancements 🔮
18. PTOMAINE and GROW 🌍
The Prefix Taxonomy (PTOMAINE) working group, recently replaced by the Global Routing Operations (GROW) working group, is chartered to consider and measure the problem of routing table growth 📈 It also looks at the effects of interactions between interior and exterior routing protocols, and the effect of address allocation policies and practices on the global routing system 🗺️ Finally, where appropriate, GROW will also document the operational aspects of measurement, policy, security, and VPN infrastructures 📝
GROW is currently studying the effects of route aggregation, and also the inability to aggregate over multiple provider boundaries due to inadequate provider coordination 🤝
Within GROW, this work is intended to result in feedback to BGPv4 and future protocol enhancements 💜
19. Internet Routing Registries (IRRs) 🗄️
Lots of organizations register their routing policy and prefix origination in the various distributed databases of the Internet Routing Registry 📚 These databases give access to information using the RPSL language, as defined in [RFC2622] 💻 Registered information may be maintained and correct for certain providers, but the lack of timely or correct data in the various IRR databases has stopped wide spread use of this resource 😩🌈
20. Regional Internet Registries (RIRs) and IRRs, A Bit of History ✨
okay so let's talk history, bestie 🧚 The NSFNET program used EGP, and then BGP, to get external routing info. The reason BGP got its first policy requirements? NSF was charging different prices and giving different levels of support to the Research and Education (RE) networks versus the Commercial (CO) networks 💅 CO networks paid more, and they also couldn't use the NSFNET backbone to reach other CO networks. The logic was that commercial users of NSFNET, inside business and research orgs, should subsidize the RE community. 🙈 Meanwhile the Internet was turning from a neat hierarchy into a mesh of peers, so people moved away from EGP and BGP-1, which got rid of any assumptions of hierarchy. Iconic glow-up energy 🌸
NSF policy was enforced through the NSF Policy Routing Database (PRDB) 👑 The PRDB didn't just record whether each network was CO or RE. It also held a list of the preferred exit points to the NSFNET for reaching each network. This is the thing that would later be called BGP LOCAL_PREF on the NSFNET, so it was lowkey foundational 🦋 Tools that came with the PRDB could generate complete router configurations for the NSFNET. Literally so useful.
Using the PRDB had a super fortunate side effect: NSFNET reliability got way better compared to peer networks of the time 🔥 The PRDB also offered more optimal routing to networks that were knowledgeable enough and willing to keep their entries current. So you had to put in the work to get the perks, periodt 💖
When the NSFNET Backbone Network Service was decommissioned in 1995, people realized the PRDB should be made less single-provider centric 🎀 Its legacy contents, plus any future updates, should be available to any provider that wanted to use it. The European networking community had long considered the PRDB too US-centric 🌈 Through Reseaux IP Europeens (RIPE), Europe created an open format in RIPE-181 and kept an open database that was used more for address and AS registry than for policy. The PRDB got converted to RIPE-181 format first, and the tools were converted to work with that format too ✨ The whole collection of databases was called the Internet Routing Registry (IRR), with the RIPE database and the US NSF-funded Routing Arbitrator (RA) as the initial components. 🫶
A need to extend RIPE-181 was spotted, and RIPE agreed to let the extensions be defined inside the IETF in the RPS WG, which gave us the RPSL language 🧚 Other RPS WG work products gave us an authentication framework and a way to widely distribute the database in a controlled manner and keep the many repositories synchronized. Freely available tools came mainly from RIPE, Merit, and ISI, with the most comprehensive set coming from ISI 💜 But ngl, the IRR participants' efforts were seriously hampered by providers who weren't willing to keep their IRR info up to date 😭 The bigger providers were vocal about it, saying that even a simple database entry is an administrative burden. Some of them even admitted that not maintaining entries gives an advantage to competitors who do use the IRR. The result? The IRR got less useful, and the Internet got more vulnerable to routing-based attacks or accidental injection of faulty routing information 💀
There have been a number of times when accidental disruption of Internet routing was avoided because providers were using the IRR, but that disruption was still highly detrimental to non-users 🙈 Filters have been forced to give less complete coverage because the IRR eroded. These kinds of disruptions still happen infrequently, but their impact is getting increasingly widespread 🌸
21. Acknowledgements 🫶
We would like to thank Paul Traina and Yakov Rekhter for authoring previous versions of this document and providing valuable input on this update 💖 We would also like to acknowledge Curtis Villamizar for providing both text and thorough reviews ✨ Thanks to Russ White, Jeffrey Haas, Sean Mentzer, Mitchell Erblich, and Jude Ballard for supplying their usual keen eyes 👀
Finally, we'd like to think the IDR WG for general and specific input that contributed to this document 🦋
22. References 📚
22.1. Normative References
[RFC1966] Bates, T. and R. Chandra, "BGP Route Reflection An
alternative to full mesh IBGP", RFC 1966, June 1996.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998.
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC 2796,
April 2000.
[RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 3065, February 2001.
[RFC4274] Meyer, D. and K. Patel, "BGP-4 Protocol Analysis", RFC
4274, January 2006.
[RFC4276] Hares, S. and A. Retana, "BGP 4 Implementation Report",
RFC 4276, January 2006.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border
Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC1657] Willis, S., Burruss, J., Chu, J., "Definitions of Managed
Objects for the Fourth Version of the Border Gateway
Protocol (BGP-4) using SMIv2", RFC 1657, July 1994.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.22.2. Informative References
[RFC1105] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1105, June 1989.
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol
(BGP)", RFC 1163, June 1990.
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet
Routing Protocol Standardization Criteria", RFC 1264,
October 1991.
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3
(BGP-3)", RFC 1267, October 1991.
[RFC1269] Willis, S. and J. Burruss, "Definitions of Managed
Objects for the Border Gateway Protocol: Version 3", RFC
1269, October 1991.
[RFC1656] Traina, P., "BGP-4 Protocol Document Roadmap and
Implementation Experience", RFC 1656, July 1994.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1773] Traina, P., "Experience with the BGP-4 protocol", RFC
1773, March 1995.
[RFC1965] Traina, P., "Autonomous System Confederations for BGP",
RFC 1965, June 1996.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens,
D., Meyer, D., Bates, T., Karrenberg, D., and M.
Terpstra, "Routing Policy Specification Language (RPSL)",
RFC 2622, June 1999.
[BGPATTACK] Convery, C., "An Attack Tree for the Border Gateway
Protocol", Work in Progress.
[SBGP] "Secure BGP", Work in Progress.
[soBGP] "Secure Origin BGP", Work in Progress.Authors' Addresses 🧑💻
Danny McPherson
Arbor Networks
EMail: danny@arbor.net
Keyur Patel
Cisco Systems
EMail: keyupate@cisco.comFull Copyright Statement ©
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🎀
📦 where this page comes from
- ietf: rfc4277 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms