diff options
Diffstat (limited to 'doc/rfc/rfc7948.txt')
| -rw-r--r-- | doc/rfc/rfc7948.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7948.txt b/doc/rfc/rfc7948.txt new file mode 100644 index 0000000..1c7ac20 --- /dev/null +++ b/doc/rfc/rfc7948.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Hilliard +Request for Comments: 7948 INEX +Category: Informational E. Jasinska +ISSN: 2070-1721 BigWave IT + R. Raszuk + Bloomberg LP + N. Bakker + Akamai Technologies B.V. + September 2016 + + + Internet Exchange BGP Route Server Operations + +Abstract + + The popularity of Internet Exchange Points (IXPs) brings new + challenges to interconnecting networks. While bilateral External BGP + (EBGP) sessions between exchange participants were historically the + most common means of exchanging reachability information over an IXP, + the overhead associated with this interconnection method causes + serious operational and administrative scaling problems for IXP + participants. + + Multilateral interconnection using Internet route servers can + dramatically reduce the administrative and operational overhead + associated with connecting to IXPs; in some cases, route servers are + used by IXP participants as their preferred means of exchanging + routing information. + + This document describes operational considerations for multilateral + interconnections at IXPs. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7948. + + + + +Hilliard, et al. Informational [Page 1] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 + 2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3 + 3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4 + 4. Operational Considerations for Route Server Installations . . 6 + 4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 + 4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 7 + 4.2.1.1. View Merging and Decomposition . . . . . . . . . 7 + 4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 8 + 4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8 + 4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8 + 4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 9 + 4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9 + 4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 10 + 4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 10 + 4.6.2. Internet Routing Registries . . . . . . . . . . . . . 10 + 4.6.3. Client-Accessible Databases . . . . . . . . . . . . . 10 + 4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 11 + 4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 11 + 4.9. BGP Operations and Security . . . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 6.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + + + + + + + +Hilliard, et al. Informational [Page 2] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +1. Introduction + + Internet Exchange Points (IXPs) provide IP data interconnection + facilities for their participants, using data link-layer protocols + such as Ethernet. The Border Gateway Protocol (BGP) [RFC4271] is + normally used to facilitate exchange of network reachability + information over these media. + + As bilateral interconnection between IXP participants requires + operational and administrative overhead, BGP route servers [RFC7947] + are often deployed by IXP operators to provide a simple and + convenient means of interconnecting IXP participants with each other. + A route server redistributes BGP routes received from its BGP clients + to other clients according to a prespecified policy, and it can be + viewed as similar to an EBGP equivalent of an Internal BGP (IBGP) + [RFC4456] route reflector. + + Route servers at IXPs require careful management, and it is important + for route server operators to thoroughly understand both how they + work and what their limitations are. In this document, we discuss + several issues of operational relevance to route server operators and + provide recommendations to help route server operators provision a + reliable interconnection service. + +1.1. Notational Conventions + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + The phrase "BGP route" in this document should be interpreted as the + term "Route" described in [RFC4271]. + +2. Bilateral BGP Sessions + + Bilateral interconnection is a method of interconnecting routers + using individual BGP sessions between each pair of participant + routers on an IXP, in order to exchange reachability information. If + an IXP participant wishes to implement an open interconnection policy + -- i.e., a policy of interconnecting with as many other IXP + participants as possible -- it is necessary for the participant to + liaise with each of their intended interconnection partners. + Interconnection can then be implemented bilaterally by configuring a + BGP session on both participants' routers to exchange network + reachability information. If each exchange participant interconnects + with each other participant, a full mesh of BGP sessions is needed, + as shown in Figure 1. + + + +Hilliard, et al. Informational [Page 3] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + ___ ___ + / \ / \ + ..| AS1 |..| AS2 |.. + : \___/____\___/ : + : | \ / | : + : | \ / | : + : IXP | \/ | : + : | /\ | : + : | / \ | : + : _|_/____\_|_ : + : / \ / \ : + ..| AS3 |..| AS4 |.. + \___/ \___/ + + Figure 1: Full-Mesh Interconnection at an IXP + + Figure 1 depicts an IXP platform with four connected routers, + administered by four separate exchange participants, each of them + with a locally unique Autonomous System (AS) number: AS1, AS2, AS3, + and AS4. The lines between the routers depict BGP sessions; the + dotted edge represents the IXP border. Each of these four + participants wishes to exchange traffic with all other participants; + this is accomplished by configuring a full mesh of BGP sessions on + each router connected to the exchange, resulting in six BGP sessions + across the IXP fabric. + + The number of BGP sessions at an exchange has an upper bound of + n*(n-1)/2, where n is the number of routers at the exchange. As many + exchanges have large numbers of participating networks, the amount of + administrative and operation overhead required to implement an open + interconnection scales quadratically. New participants to an IXP + require significant initial resourcing in order to gain value from + their IXP connection, while existing exchange participants need to + commit ongoing resources in order to benefit from interconnecting + with these new participants. + +3. Multilateral Interconnection + + Multilateral interconnection is implemented using a route server + configured to distribute BGP routes among client routers. The route + server preserves the BGP NEXT_HOP attribute from all received BGP + routes and passes them with unchanged NEXT_HOP to its route server + clients according to its configured routing policy, as described in + [RFC7947]. Using this method of exchanging BGP routes, an IXP + participant router can receive an aggregated list of BGP routes from + all other route server clients using a single BGP session to the + route server instead of depending on BGP sessions with each router at + the exchange. This reduces the overall number of BGP sessions at an + + + +Hilliard, et al. Informational [Page 4] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + Internet exchange from n*(n-1)/2 to n, where n is the number of + routers at the exchange. + + Although a route server uses BGP to exchange reachability information + with each of its clients, it does not forward traffic itself and is + therefore not a router. + + In practical terms, this allows dense interconnection between IXP + participants with low administrative overhead and significantly + simpler and smaller router configurations. In particular, new IXP + participants benefit from immediate and extensive interconnection, + while existing route server participants receive reachability + information from these new participants without necessarily having to + modify their configurations. + + ___ ___ + / \ / \ + ..| AS1 |..| AS2 |.. + : \___/ \___/ : + : \ / : + : \ / : + : \__/ : + : IXP / \ : + : | RS | : + : \____/ : + : / \ : + : / \ : + : __/ \__ : + : / \ / \ : + ..| AS3 |..| AS4 |.. + \___/ \___/ + + Figure 2: IXP-Based Interconnection with Route Server + + As illustrated in Figure 2, each router on the IXP fabric requires + only a single BGP session to the route server, from which it can + receive reachability information for all other routers on the IXP + that also connect to the route server. + + Multilateral and bilateral interconnections between different + autonomous systems are not exclusive to each other, and it is not + unusual to have both sorts of sessions configured in parallel at an + IXP. This configuration will lead to additional paths being + available to the BGP Decision Process, which will calculate a best + path as normal. + + + + + + +Hilliard, et al. Informational [Page 5] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +4. Operational Considerations for Route Server Installations + +4.1. Path Hiding + + "Path hiding" is a term used in [RFC7947] to describe the process + whereby a route server may mask individual paths by applying + conflicting routing policies to its Loc-RIB. When this happens, + route server clients receive incomplete information from the route + server about network reachability. + + There are several approaches that may be used to mitigate against the + effect of path hiding; these are described in [RFC7947]. However, + the only method that does not require explicit support from the route + server client is for the route server itself to maintain an + individual Loc-RIB for each client that is the subject of conflicting + routing policies. + +4.2. Route Server Scaling + + While deployment of multiple Loc-RIBs on the route server presents a + simple way to avoid the path-hiding problem noted in Section 4.1, + this approach requires significantly more computing resources on the + route server than where a single Loc-RIB is deployed for all clients. + As the BGP Decision Process [RFC4271] must be applied to all Loc-RIBs + deployed on the route server, both CPU and memory requirements on the + host computer scale approximately according to O(P * N), where P is + the total number of unique paths received by the route server, and N + is the number of route server clients that require a unique Loc-RIB. + As this is a super-linear scaling relationship, large route servers + may derive benefit from deploying per-client Loc-RIBs only where they + are required. + + Regardless of whether any Loc-RIB optimization technique is + implemented, the route server's theoretical upper-bound network + bandwidth requirements will scale according to O(P_tot * N), where + P_tot is the total number of unique paths received by the route + server, and N is the total number of route server clients. In the + case where P_avg (the arithmetic mean number of unique paths received + per route server client) remains roughly constant even as the number + of connected clients increases, the total number of prefixes will + equal the average number of prefixes multiplied by the number of + clients. Symbolically, this can be written as P_tot = P_avg * N. If + we assume that in the worst case, each prefix is associated with a + different set of BGP path attributes, so must be transmitted + individually, the network bandwidth scaling function can be rewritten + as O((P_avg * N) * N) or O(N^2). This quadratic upper bound on the + network traffic requirements indicates that the route server model + may not scale well for larger numbers of clients. + + + +Hilliard, et al. Informational [Page 6] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + In practice, most prefixes will be associated with a limited number + of BGP path attribute sets, allowing more efficient transmission of + BGP routes from the route server than the theoretical analysis + suggests. In the analysis above, P_tot will increase monotonically + according to the number of clients, but it will have an upper limit + of the size of the full default-free routing table of the network in + which the IXP is located. Observations from production route servers + have shown that most route server clients generally avoid using + custom routing policies, and consequently, the route server may not + need to deploy per-client Loc-RIBs. These practical bounds reduce + the theoretical worst-case scaling scenario to the point where route + server deployments are manageable even on larger IXPs. + +4.2.1. Tackling Scaling Issues + + The problem of scaling route servers still presents serious practical + challenges and requires careful attention. Scaling analysis + indicates problems in three key areas: route processor CPU overhead + associated with BGP Decision Process calculations, the memory + requirements for handling many different BGP path entries, and the + network traffic bandwidth required to distribute these BGP routes + from the route server to each route server client. + +4.2.1.1. View Merging and Decomposition + + View merging and decomposition, outlined in [RS-ARCH], describes a + method of optimizing memory and CPU requirements where multiple route + server clients are subject to exactly the same routing policies. In + this situation, multiple Loc-RIB views can be merged into a single + view. + + There are several variations of this approach. If the route server + operator has prior knowledge of interconnection relationships between + route server clients, then the operator may configure separate + Loc-RIBs only for route server clients with unique routing policies. + As this approach requires prior knowledge of interconnection + relationships, the route server operator must depend on each client + sharing their interconnection policies either in an internal + provisioning database controlled by the operator or in an external + data store such as an Internet Routing Registry Database. + + Conversely, the route server implementation itself may implement + internal view decomposition by creating virtual Loc-RIBs based on a + single in-memory master Loc-RIB, with delta differences for each + prefix subject to different routing policies. This allows a more + fine-grained and flexible approach to the problem of Loc-RIB scaling, + at the expense of requiring a more complex in-memory Loc-RIB + structure. + + + +Hilliard, et al. Informational [Page 7] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + Whatever method of view merging and decomposition is chosen on a + route server, pathological edge cases can be created whereby they + will scale no better than fully non-optimized per-client Loc-RIBs. + However, as most route server clients connect to a route server for + the purposes of reducing overhead, rather than implementing complex + per-client routing policies, edge cases tend not to arise in + practice. + +4.2.1.2. Destination Splitting + + Destination splitting, also described in [RS-ARCH], describes a + method for route server clients to connect to multiple route servers + and to send non-overlapping sets of prefixes to each route server. + As each route server computes the best path for its own set of + prefixes, the quadratic scaling requirement operates on multiple + smaller sets of prefixes. This reduces the overall computational and + memory requirements for managing multiple Loc-RIBs and performing the + best-path calculation on each. + + In practice, the route server operator would need all route server + clients to send a full set of BGP routes to each route server. The + route server operator could then selectively filter these prefixes + for each route server by using either BGP Outbound Route Filtering + [RFC5291] or inbound prefix filters configured on client BGP + sessions. + +4.2.1.3. NEXT_HOP Resolution + + As route servers are usually deployed at IXPs where all connected + routers are on the same Layer 2 broadcast domain, recursive + resolution of the NEXT_HOP attribute is generally not required and + can be replaced by a simple check to ensure that the NEXT_HOP value + for each received BGP route is a network address on the IXP LAN's IP + address range. + +4.3. Prefix Leakage Mitigation + + Prefix leakage occurs when a BGP client unintentionally distributes + BGP routes to one or more neighboring BGP routers. Prefix leakage of + this form to a route server can cause serious connectivity problems + at an IXP if each route server client is configured to accept all BGP + routes from the route server. It is therefore RECOMMENDED when + deploying route servers that, due to the potential for collateral + damage caused by BGP route leakage, route server operators deploy + prefix leakage mitigation measures in order to prevent unintentional + prefix announcements or else limit the scale of any such leak. + Although not foolproof, per-client inbound prefix limits can restrict + the damage caused by prefix leakage in many cases. Per-client + + + +Hilliard, et al. Informational [Page 8] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + inbound prefix filtering on the route server is a more deterministic + and usually more reliable means of preventing prefix leakage but + requires more administrative resources to maintain properly. + + If a route server operator implements per-client inbound prefix + filtering, then it is RECOMMENDED that the operator also builds in + mechanisms to automatically compare the Adj-RIB-In received from each + client with the inbound prefix lists configured for those clients. + Naturally, it is the responsibility of the route server client to + ensure that their stated prefix list is compatible with what they + announce to an IXP route server. However, many network operators do + not carefully manage their published routing policies, and it is not + uncommon to see significant variation between the two sets of + prefixes. Route server operator visibility into this discrepancy can + provide significant advantages to both operator and client. + +4.4. Route Server Redundancy + + As the purpose of an IXP route server implementation is to provide a + reliable reachability brokerage service, it is RECOMMENDED that + exchange operators who implement route server systems provision + multiple route servers on each shared Layer 2 domain. There is no + requirement to use the same BGP implementation or operating system + for each route server on the IXP fabric; however, it is RECOMMENDED + that where an operator provisions more than a single server on the + same shared Layer 2 domain, each route server implementation be + configured equivalently and in such a manner that the path + reachability information from each system is identical. + +4.5. AS_PATH Consistency Check + + [RFC4271] requires that every BGP speaker that advertises a BGP route + to another external BGP speaker prepends its own AS number as the + last element of the AS_PATH sequence. Therefore, the leftmost AS in + an AS_PATH attribute should be equal to the AS number of the BGP + speaker that sent the BGP route. + + As [RFC7947] suggests that route servers should not modify the + AS_PATH attribute, a consistency check on the AS_PATH of a BGP route + received by a route server client would normally fail. It is + therefore RECOMMENDED that route server clients disable the AS_PATH + consistency check towards the route server. + + + + + + + + + +Hilliard, et al. Informational [Page 9] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +4.6. Export Routing Policies + + Policy filtering is commonly implemented on route servers to provide + prefix distribution control mechanisms for route server clients. A + route server "export" policy is a policy that affects prefixes sent + from the route server to a route server client. Several different + strategies are commonly used for implementing route server export + policies. + +4.6.1. BGP Communities + + Prefixes sent to the route server are tagged with specific standard + BGP Communities [RFC1997] or Extended Communities [RFC4360] + attributes, based on predefined values agreed between the operator + and all clients. Based on these Communities values, BGP routes may + be propagated to all other clients, a subset of clients, or none. + This mechanism allows route server clients to instruct the route + server to implement per-client export routing policies. + + As both standard BGP Communities and Extended Communities values are + restricted to 6 octets or fewer, it is not possible for both the + global and local administrator fields in the BGP Communities value to + fit a 4-octet AS number. Bearing this in mind, the route server + operator SHOULD take care to ensure that the predefined BGP + Communities values mechanism used on their route server is compatible + with 4-octet AS numbers [RFC6793]. + +4.6.2. Internet Routing Registries + + Internet Routing Registry databases (IRRDBs) may be used by route + server operators to construct per-client routing policies. "Routing + Policy Specification Language (RPSL)" [RFC2622] provides a + comprehensive grammar for describing interconnection relationships, + and several toolsets exist that can be used to translate RPSL policy + description into route server configurations. + +4.6.3. Client-Accessible Databases + + Should the route server operator not wish to use either BGP + Communities or the public IRRDBs for implementing client export + policies, they may implement their own routing policy database system + for managing their clients' requirements. A database of this form + SHOULD allow a route server client operator to update their routing + policy and provide a mechanism for allowing the client to specify + whether they wish to exchange all their prefixes with any other route + server client. Optionally, the implementation may allow a client to + specify unique routing policies for individual prefixes over which + they have routing policy control. + + + +Hilliard, et al. Informational [Page 10] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +4.7. Layer 2 Reachability Problems + + Layer 2 reachability problems on an IXP can cause serious operational + problems for IXP participants that depend on route servers for + interconnection. Ethernet switch forwarding bugs have occasionally + been observed to cause non-transitive reachability. For example, + given a route server and two IXP participants, A and B, if the two + participants can reach the route server but cannot reach each other, + then traffic between the participants may be dropped until such time + as the Layer 2 forwarding problem is resolved. This situation does + not tend to occur in bilateral interconnection arrangements, as the + routing control path between the two hosts is usually (but not + always, due to IXP inter-switch connectivity load-balancing + algorithms) the same as the data path between them. + + Problems of this form can be partially mitigated by using + Bidirectional Forwarding Detection (BFD) [RFC5881]. However, as this + is a bilateral protocol configured between routers, and as there is + currently no protocol to automatically configure BFD sessions between + route server clients, BFD does not currently provide an optimal means + of handling the problem. Even if automatic BFD session configuration + were possible, practical problems would remain. If two IXP route + server clients were configured to run BFD between each other and the + protocol detected a non-transitive loss of reachability between them, + each of those routers would internally mark the other's prefixes as + unreachable via the BGP path announced by the route server. As the + route server only propagates a single best path to each client, this + could cause either sub-optimal routing or complete connectivity loss + if there were no alternative paths learned from other BGP sessions. + +4.8. BGP NEXT_HOP Hijacking + + Item 2 in Section 5.1.3 of [RFC4271] allows EBGP speakers to change + the NEXT_HOP address of a received BGP route to be a different + Internet address on the same subnet. This is the mechanism that + allows route servers to operate on a shared Layer 2 IXP network. + However, the mechanism can be abused by route server clients to + redirect traffic for their prefixes to other IXP participant routers. + + + + + + + + + + + + + +Hilliard, et al. Informational [Page 11] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + ____ + / \ + | AS99 | + \____/ + / \ + / \ + __/ \__ + / \ / \ + ..| AS1 |..| AS2 |.. + : \___/ \___/ : + : \ / : + : \ / : + : \__/ : + : IXP / \ : + : | RS | : + : \____/ : + : : + .................... + + Figure 3: BGP NEXT_HOP Hijacking Using a Route Server + + For example, in Figure 3, if AS1 and AS2 both announce BGP routes for + AS99 to the route server, AS1 could set the NEXT_HOP address for + AS99's routes to be the address of AS2's router, thereby diverting + traffic for AS99 via AS2. This may override the routing policies of + AS99 and AS2. + + Worse still, if the route server operator does not use inbound prefix + filtering, AS1 could announce any arbitrary prefix to the route + server with a NEXT_HOP address of any other IXP participant. This + could be used as a denial-of-service mechanism against either the + users of the address space being announced by illicitly diverting + their traffic or the other IXP participant by overloading their + network with traffic that would not normally be sent there. + + This problem is not specific to route servers, and it can also be + implemented using bilateral BGP sessions. However, the potential + damage is amplified by route servers because a single BGP session can + be used to affect many networks simultaneously. + + Because route server clients cannot easily implement next-hop policy + checks against route server BGP sessions, route server operators + SHOULD check that the BGP NEXT_HOP attribute for BGP routes received + from a route server client matches the interface address of the + client. If the route server receives a BGP route where these + addresses are different and where the announcing route server client + is in a different AS to the route server client that uses the next- + hop address, the BGP route SHOULD be dropped. Permitting next-hop + + + +Hilliard, et al. Informational [Page 12] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + + rewriting for the same AS allows an organization with multiple + connections into an IXP configured with different IP addresses to + direct traffic off the IXP infrastructure through any of their + connections for traffic engineering or other purposes. + +4.9. BGP Operations and Security + + BGP route servers SHOULD be configured and operated in compliance + with [RFC7454] with the exception of Section 11, "BGP Community + Scrubbing", which may not necessarily apply on a route server, + depending on the route server operator policy. + +5. Security Considerations + + On route server installations that do not employ path-hiding + mitigation techniques, the path-hiding problem outlined in + Section 4.1 could be used by an IXP participant to prevent the route + server from sending any BGP routes for a particular prefix to other + route server clients, even if there was a valid path to that + destination via another route server client. + + If the route server operator does not implement prefix leakage + mitigation as described in Section 4.3, it is trivial for route + server clients to implement denial-of-service attacks against + arbitrary Internet networks by leaking BGP routes to a route server. + + Route server installations SHOULD be secured against BGP NEXT_HOP + hijacking, as described in Section 4.8. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, + "Internet Exchange BGP Route Server", RFC 7947, + DOI 10.17487/RFC7947, September 2016, + <http://www.rfc-editor.org/info/rfc7947>. + + + + + + + + + +Hilliard, et al. Informational [Page 13] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +6.2. Informative References + + [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities + Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, + <http://www.rfc-editor.org/info/rfc1997>. + + [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, + DOI 10.17487/RFC2622, June 1999, + <http://www.rfc-editor.org/info/rfc2622>. + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, + DOI 10.17487/RFC4271, January 2006, + <http://www.rfc-editor.org/info/rfc4271>. + + [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended + Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, + February 2006, <http://www.rfc-editor.org/info/rfc4360>. + + [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route + Reflection: An Alternative to Full Mesh Internal BGP + (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, + <http://www.rfc-editor.org/info/rfc4456>. + + [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering + Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, + August 2008, <http://www.rfc-editor.org/info/rfc5291>. + + [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, + DOI 10.17487/RFC5881, June 2010, + <http://www.rfc-editor.org/info/rfc5881>. + + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + <http://www.rfc-editor.org/info/rfc6793>. + + [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations + and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, + February 2015, <http://www.rfc-editor.org/info/rfc7454>. + + [RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D. + Estrin, "A Route Server Architecture for Inter-Domain + Routing", 1995, + <http://www.cs.usc.edu/assets/003/83191.pdf>. + + + +Hilliard, et al. Informational [Page 14] + +RFC 7948 IXP BGP Route Server Operations September 2016 + + +Acknowledgments + + The authors would like to thank Chris Hall, Ryan Bickhart, Steven + Bakker, and Eduardo Ascenco Reis for their valuable input. + +Authors' Addresses + + Nick Hilliard + INEX + 4027 Kingswood Road + Dublin 24 + Ireland + + Email: nick@inex.ie + + + Elisa Jasinska + BigWave IT + ul. Skawinska 27/7 + Krakow, MP 31-066 + Poland + + Email: elisa@bigwaveit.org + + + Robert Raszuk + Bloomberg LP + 731 Lexington Ave. + New York, NY 10022 + United States of America + + Email: robert@raszuk.net + + + Niels Bakker + Akamai Technologies B.V. + Kingsfordweg 151 + Amsterdam 1043 GR + Netherlands + + Email: nbakker@akamai.com + + + + + + + + + + +Hilliard, et al. Informational [Page 15] + |