[要約] RFC 7948は、インターネット交換BGPルートサーバーの運用に関するガイドラインです。このRFCの目的は、BGPルートサーバーの運用者に対して、効果的な運用方法とベストプラクティスを提供することです。
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
Internet Exchange BGPルートサーバーの操作
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.
インターネットエクスチェンジポイント（IXP）の人気は、ネットワークの相互接続に新たな課題をもたらします。交換参加者間の双方向の外部BGP（EBGP）セッションは、これまでIXPを介して到達可能性情報を交換する最も一般的な手段でしたが、この相互接続方法に関連するオーバーヘッドは、IXP参加者に運用上および管理上の重大なスケーリング問題を引き起こします。
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.
インターネットルートサーバーを使用した多国間相互接続により、IXPへの接続に関連する管理上および運用上のオーバーヘッドを大幅に削減できます。場合によっては、ルーティングサーバーは、ルーティング情報を交換する優先手段としてIXP参加者によって使用されます。
This document describes operational considerations for multilateral interconnections at IXPs.
このドキュメントでは、IXPでの多国間相互接続に関する運用上の考慮事項について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
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.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7948で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、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
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.
インターネット交換ポイント（IXP）は、イーサネットなどのデータリンク層プロトコルを使用して、参加者にIPデータ相互接続機能を提供します。ボーダーゲートウェイプロトコル（BGP）[RFC4271]は通常、これらのメディアを介したネットワーク到達可能性情報の交換を容易にするために使用されます。
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.
IXP参加者間の双方向の相互接続には運用上および管理上のオーバーヘッドが必要であるため、IXP参加者を相互に相互接続するシンプルで便利な手段を提供するために、BGPルートサーバー[RFC7947]がIXPオペレーターによって展開されることがよくあります。ルートサーバーは、事前に指定されたポリシーに従って、BGPクライアントから受信したBGPルートを他のクライアントに再配布します。これは、内部BGP（IBGP）[RFC4456]ルートリフレクターと同等のEBGPと同様に見ることができます。
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.
IXPのルートサーバーは慎重に管理する必要があります。ルートサーバーのオペレーターは、サーバーの動作と制限について十分に理解することが重要です。このドキュメントでは、ルーティングサーバーオペレーターの運用上の関連性のいくつかの問題について説明し、ルートサーバーオペレーターが信頼できる相互接続サービスを提供するのに役立つ推奨事項を示します。
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」このドキュメントの[RFC2119]で説明されているように解釈されます。
The phrase "BGP route" in this document should be interpreted as the term "Route" described in [RFC4271].
このドキュメントの「BGPルート」というフレーズは、[RFC4271]で説明されている「ルート」という用語として解釈されるべきです。
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.
双方向相互接続は、到達可能性情報を交換するために、IXP上の参加者ルーターの各ペア間で個別のBGPセッションを使用してルーターを相互接続する方法です。 IXP参加者がオープン相互接続ポリシー（つまり、できるだけ多くの他のIXP参加者と相互接続するポリシー）を実装したい場合、参加者はそれぞれの意図する相互接続パートナーと連絡を取る必要があります。相互接続は、両方の参加者のルーターでBGPセッションを構成してネットワークの到達可能性情報を交換することにより、双方向で実装できます。各交換参加者が他の参加者と相互接続する場合、図1に示すように、BGPセッションのフルメッシュが必要です。
___ ___
/ \ / \
..| AS1 |..| AS2 |..
: \___/____\___/ :
: | \ / | :
: | \ / | :
: IXP | \/ | :
: | /\ | :
: | / \ | :
: _|_/____\_|_ :
: / \ / \ :
..| AS3 |..| AS4 |..
\___/ \___/
Figure 1: Full-Mesh Interconnection at an IXP
図1：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.
図1は、4つの接続されたルーターを備えたIXPプラットフォームを示しています。これらのルーターは、それぞれがローカルで一意の自律システム（AS）番号（AS1、AS2、AS3、およびAS4）を持つ4つの個別の交換参加者によって管理されています。ルーター間の線はBGPセッションを表しています。点線のエッジはIXP境界を表します。これら4人の参加者はそれぞれ、他のすべての参加者とトラフィックを交換したいと考えています。これは、交換に接続されている各ルーターでBGPセッションのフルメッシュを構成することで実現され、IXPファブリック全体で6つのBGPセッションが発生します。
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.
交換でのBGPセッションの数には、n *（n-1）/ 2の上限があります。ここで、nは交換でのルーターの数です。多くの取引所には多数の参加ネットワークがあるため、オープン相互接続を実装するために必要な管理および運用オーバーヘッドの量は、二次的にスケーリングします。 IXPへの新規参加者は、IXP接続から価値を得るためにかなりの初期リソースを必要としますが、既存の交換参加者は、これらの新規参加者との相互接続から利益を得るために継続的なリソースを投入する必要があります。
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 Internet exchange from n*(n-1)/2 to n, where n is the number of routers at the exchange.
マルチラテラル相互接続は、BGPルートをクライアントルーター間で分散するように構成されたルートサーバーを使用して実装されます。 [RFC7947]で説明されているように、ルートサーバーは、受信したすべてのBGPルートからBGP NEXT_HOP属性を保持し、それらを変更されていないNEXT_HOPとともに、構成されたルーティングポリシーに従ってルートサーバークライアントに渡します。 BGPルートを交換するこの方法を使用すると、IXP参加者ルーターは、交換所の各ルーターとのBGPセッションに依存する代わりに、単一のBGPセッションを使用して他のすべてのルートサーバークライアントからルートサーバーへのBGPルートの集約リストを受信できます。これにより、インターネット交換でのBGPセッションの総数がn *（n-1）/ 2からnに減少します。ここで、nは交換にあるルーターの数です。
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.
ルートサーバーはBGPを使用して各クライアントとの到達可能性情報を交換しますが、それ自体はトラフィックを転送しないため、ルーターではありません。
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.
実際には、これにより、管理上のオーバーヘッドが少なく、非常にシンプルで小型のルーター構成で、IXP参加者間の密な相互接続が可能になります。特に、新しいIXP参加者は即時かつ広範囲の相互接続の恩恵を受ける一方で、既存のルートサーバー参加者は、構成を変更する必要なく、これらの新しい参加者から到達可能性情報を受信します。
___ ___
/ \ / \
..| AS1 |..| AS2 |..
: \___/ \___/ :
: \ / :
: \ / :
: \__/ :
: IXP / \ :
: | RS | :
: \____/ :
: / \ :
: / \ :
: __/ \__ :
: / \ / \ :
..| AS3 |..| AS4 |..
\___/ \___/
Figure 2: IXP-Based Interconnection with Route Server
図2：ルートサーバーとのIXPベースの相互接続
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.
図2に示すように、IXPファブリック上の各ルーターは、ルートサーバーへの単一のBGPセッションのみを必要とし、そこからルートサーバーに接続するIXP上の他のすべてのルーターの到達可能性情報を受信できます。
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.
異なる自律システム間の多国間および双方向の相互接続は互いに排他的ではなく、IXPで両方の種類のセッションを並行して構成することも珍しくありません。この構成により、BGP決定プロセスで追加のパスが利用可能になり、通常どおりに最適なパスが計算されます。
"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.
「パス隠蔽」は、[RFC7947]で使用されている用語であり、ルートサーバーがLoc-RIBに競合するルーティングポリシーを適用することにより、個々のパスをマスクするプロセスを説明しています。これが発生すると、ルートサーバークライアントは、ルートサーバーからネットワークの到達可能性に関する不完全な情報を受け取ります。
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.
パスの非表示の影響を軽減するために使用できる方法はいくつかあります。これらは[RFC7947]で説明されています。ただし、ルートサーバークライアントからの明示的なサポートを必要としない唯一の方法は、ルートサーバー自体が、競合するルーティングポリシーの対象である各クライアントの個別のLoc-RIBを維持することです。
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.
ルートサーバーに複数のLoc-RIBを配置すると、セクション4.1で説明したパスを隠す問題を回避する簡単な方法が提供されますが、このアプローチでは、すべてのクライアントに単一のLoc-RIBを配置する場合よりも、ルートサーバーにかなり多くのコンピューティングリソースが必要になります。 。 BGP決定プロセス[RFC4271]はルートサーバーに展開されたすべてのLoc-RIBに適用する必要があるため、ホストコンピューターのCPUとメモリの要件は、ほぼO（P * N）に従ってスケーリングされます。ここで、Pは一意の総数です。ルートサーバーが受信したパス。Nは、一意のLoc-RIBを必要とするルートサーバークライアントの数です。これは超線形のスケーリング関係であるため、大規模なルートサーバーは、必要な場所にのみクライアントごとのLoc-RIBを展開することでメリットを得ることができます。
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.
Loc-RIB最適化手法が実装されているかどうかに関係なく、ルートサーバーの理論上の上限ネットワーク帯域幅要件は、O（P_tot * N）に従ってスケーリングされます。ここで、P_totはルートサーバーが受信した一意のパスの総数であり、Nルートサーバークライアントの総数です。 P_avg（ルートサーバークライアントごとに受信される一意のパスの算術平均数）が、接続されたクライアントの数が増加してもほぼ一定である場合、プレフィックスの総数は、プレフィックスの平均数にクライアント数を掛けたものに等しくなります。シンボリックに、これはP_tot = P_avg * Nと書くことができます。最悪の場合、各プレフィックスはBGPパス属性の異なるセットに関連付けられているため、個別に送信する必要があるため、ネットワーク帯域幅スケーリング関数は次のように書き直すことができます。 O（（P_avg * N）* N）またはO（N ^ 2）。このネットワークトラフィック要件の2次上限は、ルートサーバーモデルが多数のクライアントに対して適切にスケーリングしない可能性があることを示しています。
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.
実際には、ほとんどのプレフィックスは限られた数のBGPパス属性セットに関連付けられるため、理論的分析が示唆するよりも効率的にルートサーバーからBGPルートを送信できます。上記の分析では、P_totはクライアントの数に応じて単調に増加しますが、IXPが配置されているネットワークのデフォルトのないルーティングテーブル全体のサイズには上限があります。プロダクションルートサーバーからの観察によると、ほとんどのルートサーバークライアントは通常、カスタムルーティングポリシーの使用を避け、その結果、ルートサーバーはクライアントごとのLoc-RIBを展開する必要がない場合があります。これらの実際的な境界により、理論的な最悪の場合のスケーリングシナリオが、大規模なIXPでもルートサーバーの展開を管理できるところまで減少します。
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.
ルートサーバーのスケーリングの問題は、依然として深刻な実用上の課題を提示しており、注意深い注意が必要です。スケーリング分析は、BGP決定プロセスの計算に関連するルートプロセッサのCPUオーバーヘッド、多くの異なるBGPパスエントリを処理するためのメモリ要件、これらのBGPルートをルートサーバーから各ルートサーバーに配布するために必要なネットワークトラフィック帯域幅の3つの主要な領域に問題があることを示しています。クライアント。
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.
[RS-ARCH]で概説されているビューのマージと分解では、複数のルートサーバークライアントがまったく同じルーティングポリシーの対象となる場合のメモリとCPUの要件を最適化する方法について説明しています。この状況では、複数のLoc-RIBビューを1つのビューにマージできます。
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.
このアプローチにはいくつかのバリエーションがあります。ルートサーバーオペレーターがルートサーバークライアント間の相互接続関係について事前に知っている場合、オペレーターは、一意のルーティングポリシーを持つルートサーバークライアントに対してのみ個別のLoc-RIBを構成できます。このアプローチには相互接続関係の事前知識が必要であるため、ルートサーバーオペレーターは、オペレーターが制御する内部プロビジョニングデータベースまたはインターネットルーティングレジストリデータベースなどの外部データストアで相互接続ポリシーを共有する各クライアントに依存する必要があります。
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.
逆に、ルートサーバーの実装自体は、単一のメモリ内マスターLoc-RIBに基づいて仮想Loc-RIBを作成することにより、内部プレフィックスを実装できます。各プレフィックスの差分は、異なるルーティングポリシーに従います。これにより、より複雑でメモリ内のLoc-RIB構造が必要になる代わりに、Loc-RIBスケーリングの問題に対してよりきめ細かく柔軟なアプローチが可能になります。
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.
ルートサーバーでどのようなビューのマージと分解の方法を選択しても、完全に最適化されていないクライアントごとのLoc-RIBと同様に、異常なエッジケースを作成できます。ただし、ほとんどのルートサーバークライアントは、複雑なクライアントごとのルーティングポリシーを実装するのではなく、オーバーヘッドを減らす目的でルートサーバーに接続するため、実際にはエッジケースは発生しません。
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.
[RS-ARCH]でも説明されている宛先分割では、ルートサーバークライアントが複数のルートサーバーに接続し、重複しない一連のプレフィックスを各ルートサーバーに送信する方法が説明されています。各ルートサーバーは独自のプレフィックスセットの最適パスを計算するので、二次スケーリング要件は複数の小さなプレフィックスセットで動作します。これにより、複数のLoc-RIBを管理し、それぞれに最適パス計算を実行するための全体的な計算およびメモリ要件が軽減されます。
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.
実際には、ルートサーバーオペレーターは、すべてのルートサーバークライアントが各ルートサーバーにBGPルートのフルセットを送信する必要があります。ルートサーバーオペレーターは、BGPアウトバウンドルートフィルタリング[RFC5291]またはクライアントのBGPセッションで構成されたインバウンドプレフィックスフィルターを使用して、ルートサーバーごとにこれらのプレフィックスを選択的にフィルタリングできます。
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.
ルートサーバーは通常、すべての接続されたルーターが同じレイヤー2ブロードキャストドメイン上にあるIXPに展開されるため、通常、NEXT_HOP属性の再帰解決は不要であり、受信した各BGPルートのNEXT_HOP値を確認する簡単なチェックで置き換えることができます。 IXP LANのIPアドレス範囲のネットワークアドレスです。
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 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.
プレフィックスリークは、BGPクライアントが意図せずに1つ以上の隣接するBGPルーターにBGPルートを配布したときに発生します。このフォームのルートサーバーへのプレフィックスリークは、各ルートサーバークライアントがルートサーバーからのすべてのBGPルートを受け入れるように構成されている場合、IXPで深刻な接続の問題を引き起こす可能性があります。したがって、ルートサーバーを展開する場合は、BGPルートリークによって引き起こされる副次的な損傷の可能性があるため、ルートサーバーオペレーターが意図しないプレフィックスのアナウンスを防止するために、またはそのようなリークの規模を制限するために、プレフィックスリークの緩和策を展開することをお勧めします。確実ではありませんが、クライアントごとのインバウンドプレフィックス制限により、多くの場合、プレフィックスリークによる被害を制限できます。ルートサーバーでのクライアントごとのインバウンドプレフィックスフィルタリングは、より確定的で、通常はプレフィックスリークを防ぐより信頼性の高い手段ですが、適切に維持するにはより多くの管理リソースが必要です。
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.
ルートサーバーオペレーターがクライアントごとの受信プレフィックスフィルターを実装する場合、オペレーターは、各クライアントから受信したAdj-RIB-Inをそれらのクライアント用に構成された受信プレフィックスリストと自動的に比較するメカニズムを組み込むことも推奨されます。当然、ルートサーバークライアントは、指定されたプレフィックスリストがIXPルートサーバーにアナウンスされるものと互換性があることを確認する必要があります。ただし、多くのネットワークオペレーターは、公開されたルーティングポリシーを慎重に管理していません。また、2組のプレフィックス間で大きな違いが見られることも珍しくありません。ルートのサーバーオペレーターがこの不一致を可視化することで、オペレーターとクライアントの両方に大きな利点がもたらされます。
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.
IXPルートサーバー実装の目的は、信頼性のある到達可能性仲介サービスを提供することであるため、ルートサーバーシステムを実装する交換事業者は、各共有レイヤー2ドメインに複数のルートサーバーをプロビジョニングすることをお勧めします。 IXPファブリック上の各ルートサーバーに同じBGP実装またはオペレーティングシステムを使用する必要はありません。ただし、オペレーターが同じ共有レイヤー2ドメインに複数のサーバーをプロビジョニングする場合、各ルートサーバーの実装は同等に、各システムからのパス到達可能性情報が同じになるように構成することをお勧めします。
[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.
[RFC4271]では、BGPルートを別の外部BGPスピーカーにアドバタイズするすべてのBGPスピーカーが、独自のAS番号をAS_PATHシーケンスの最後の要素として付加する必要があります。したがって、AS_PATH属性の左端のASは、BGPルートを送信したBGPスピーカーのAS番号と同じである必要があります。
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.
[RFC7947]はルートサーバーがAS_PATH属性を変更してはならないことを示唆しているため、ルートサーバークライアントが受信したBGPルートのAS_PATHの整合性チェックは通常失敗します。したがって、ルートサーバークライアントは、ルートサーバーに対するAS_PATH整合性チェックを無効にすることをお勧めします。
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.
ポリシーフィルタリングは一般にルートサーバーに実装され、ルートサーバークライアントにプレフィックス配布制御メカニズムを提供します。ルートサーバーの「エクスポート」ポリシーは、ルートサーバーからルートサーバークライアントに送信されるプレフィックスに影響を与えるポリシーです。ルートサーバーエクスポートポリシーの実装には、いくつかの異なる戦略が一般的に使用されます。
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.
ルートサーバーに送信されるプレフィックスは、オペレーターとすべてのクライアント間で合意された事前定義値に基づいて、特定の標準BGPコミュニティ[RFC1997]または拡張コミュニティ[RFC4360]属性でタグ付けされます。これらのコミュニティ値に基づいて、BGPルートは他のすべてのクライアント、クライアントのサブセット、またはなしに伝播される場合があります。このメカニズムにより、ルートサーバークライアントは、クライアントごとのエクスポートルーティングポリシーを実装するようにルートサーバーに指示できます。
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].
標準のBGPコミュニティと拡張コミュニティの値はどちらも6オクテット以下に制限されているため、BGPコミュニティ値のグローバル管理者フィールドとローカル管理者フィールドの両方を4オクテットのAS番号に適合させることはできません。これを念頭に置いて、ルートサーバーオペレーターは、ルートサーバーで使用される定義済みのBGPコミュニティ値メカニズムが4オクテットのAS番号[RFC6793]と互換性があることを確認する必要があります（SHOULD）。
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.
ルートサーバーオペレーターは、インターネットルーティングレジストリデータベース（IRRDB）を使用して、クライアントごとのルーティングポリシーを構築できます。 「ルーティングポリシー仕様言語（RPSL）」[RFC2622]は、相互接続関係を記述するための包括的な文法を提供し、RPSLポリシー記述をルートサーバー構成に変換するために使用できるいくつかのツールセットが存在します。
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.
ルートサーバーオペレーターがクライアントエクスポートポリシーの実装にBGPコミュニティまたはパブリックIRRDBのいずれも使用したくない場合は、クライアントの要件を管理するために独自のルーティングポリシーデータベースシステムを実装できます。この形式のデータベースは、ルートサーバーのクライアントオペレーターがルーティングポリシーを更新し、すべてのプレフィックスを他のルートサーバークライアントと交換するかどうかをクライアントが指定できるようにするメカニズムを提供する必要があります（SHOULD）。オプションで、実装により、クライアントはルーティングポリシーを制御する個々のプレフィックスに対して一意のルーティングポリシーを指定できます。
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.
IXPでのレイヤ2到達可能性の問題は、相互接続をルートサーバーに依存するIXP参加者に重大な運用上の問題を引き起こす可能性があります。イーサネットスイッチ転送のバグにより、非推移的な到達可能性が発生する場合があります。たとえば、ルートサーバーと2人のIXP参加者AおよびBが存在する場合、2人の参加者がルートサーバーに到達できても互いに到達できない場合、レイヤー2転送の問題が解決されるまで、参加者間のトラフィックがドロップされる可能性があります。 。 2つのホスト間のルーティング制御パスは通常（ただし常にではないが、IXPのスイッチ間接続ロードバランシングアルゴリズムにより）、それらの間のデータパスと同じであるため、このような状況は双方向相互接続では発生しません。
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.
この形式の問題は、双方向転送検出（BFD）[RFC5881]を使用することで部分的に軽減できます。ただし、これはルーター間で構成される双方向プロトコルであり、現在ルートサーバークライアント間のBFDセッションを自動的に構成するプロトコルがないため、BFDは現在、問題を処理する最適な手段を提供していません。自動BFDセッション設定が可能であったとしても、実際的な問題は残ります。 2つのIXPルートサーバークライアントが相互にBFDを実行するように構成されていて、プロトコルがそれらの間の到達可能性の非推移的な損失を検出した場合、これらのルーターはそれぞれ、ルートサーバーによってアナウンスされたBGPパスを介して到達不能として他のプレフィックスを内部的にマークします。ルートサーバーは1つの最適なパスを各クライアントに伝達するだけなので、他のBGPセッションから学習した代替パスがない場合、最適化されていないルーティングが発生するか、接続が完全に失われる可能性があります。
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.
[RFC4271]のセクション5.1.3のアイテム2により、EBGPスピーカーは、受信したBGPルートのNEXT_HOPアドレスを同じサブネット上の別のインターネットアドレスに変更できます。これは、ルートサーバーが共有レイヤー2 IXPネットワーク上で動作できるようにするメカニズムです。ただし、ルートサーバークライアントがメカニズムを悪用して、プレフィックスのトラフィックを他のIXP参加者ルーターにリダイレクトする可能性があります。
____
/ \
| AS99 |
\____/
/ \
/ \
__/ \__
/ \ / \
..| AS1 |..| AS2 |..
: \___/ \___/ :
: \ / :
: \ / :
: \__/ :
: IXP / \ :
: | RS | :
: \____/ :
: :
....................
Figure 3: BGP NEXT_HOP Hijacking Using a Route Server
図3：ルートサーバーを使用したBGP NEXT_HOPハイジャック
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.
たとえば、図3で、AS1とAS2の両方がAS99のBGPルートをルートサーバーにアナウンスする場合、AS1はAS99のルートのNEXT_HOPアドレスをAS2のルーターのアドレスに設定し、AS2を介してAS99のトラフィックを迂回させることができます。これにより、AS99および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.
さらに悪いことに、ルートサーバーオペレーターがインバウンドプレフィックスフィルタリングを使用しない場合、AS1は他のIXP参加者のNEXT_HOPアドレスを使用してルートサーバーに任意のプレフィックスを通知できます。これは、不法にトラフィックを転用することによってアナウンスされるアドレススペースのユーザー、または通常はそこに送信されないトラフィックでネットワークに過負荷をかけることによって他のIXP参加者に対するサービス拒否メカニズムとして使用できます。
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.
この問題はルートサーバーに固有のものではなく、双方向BGPセッションを使用して実装することもできます。ただし、単一のBGPセッションを使用して同時に多くのネットワークに影響を与えることができるため、ルートサーバーによって潜在的な損傷が増幅されます。
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 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.
ルートサーバークライアントは、ルートサーバーBGPセッションに対するネクストホップポリシーチェックを簡単に実装できないため、ルートサーバーオペレーターは、ルートサーバークライアントから受信したBGPルートのBGP NEXT_HOP属性がクライアントのインターフェイスアドレスと一致することを確認する必要があります（SHOULD）。ルートサーバーがこれらのアドレスが異なり、アナウンスルートサーバークライアントがネクストホップアドレスを使用するルートサーバークライアントとは異なるASにあるBGPルートを受信した場合、BGPルートを削除する必要があります（SHOULD）。同じASのネクストホップの書き換えを許可すると、異なるIPアドレスで構成されたIXPへの複数の接続を持つ組織が、トラフィックエンジニアリングやその他の目的で、任意の接続を介してIXPインフラストラクチャからトラフィックを転送できます。
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.
BGPルートサーバーは、セクション11「BGPコミュニティスクラビング」を除いて[RFC7454]に準拠して構成および運用する必要があります。ただし、ルートサーバーオペレーターのポリシーによっては、ルートサーバーに適用されるとは限りません。
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.
パスを隠す緩和技術を採用していないルートサーバーのインストールでは、セクション4.1で概説されているパスを隠す問題をIXP参加者が使用して、ルートサーバーが特定のプレフィックスのBGPルートを他のルートサーバークライアントに送信しないようにすることができます。別のルートサーバークライアントを介してその宛先への有効なパスがあったとしても。
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.
セクション4.3で説明されているようにルートサーバーオペレーターがプレフィックスリークの緩和を実装していない場合、ルートサーバークライアントがBGPルートをルートサーバーにリークすることにより、任意のインターネットネットワークに対してサービス拒否攻撃を実装することは簡単です。
Route server installations SHOULD be secured against BGP NEXT_HOP hijacking, as described in Section 4.8.
ルートサーバーのインストールは、セクション4.8で説明されているように、BGP NEXT_HOPハイジャックから保護する必要があります（SHOULD）。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC7947] Jasinska、E.、Hilliard、N.、Raszuk、R。、およびN. Bakker、「Internet Exchange BGP Route Server」、RFC 7947、DOI 10.17487 / RFC7947、2016年9月、<http：//www.rfc -editor.org/info/rfc7947>。
[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>.
[RFC1997] Chandra、R.、Traina、P。、および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>.
[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、1999年6月、<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>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<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>.
[RFC4360] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP Extended Communities Attribute」、RFC 4360、DOI 10.17487 / RFC4360、2006年2月、<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>.
[RFC4456]ベイツ、T。、チェン、E。、およびR.チャンドラ、「BGPルートリフレクション：フルメッシュ内部BGP（IBGP）の代替」、RFC 4456、DOI 10.17487 / RFC4456、2006年4月、<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>.
[RFC5291] Chen、E。およびY. Rekhter、「BGP-4のアウトバウンドルートフィルタリング機能」、RFC 5291、DOI 10.17487 / RFC5291、2008年8月、<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>.
[RFC5881] Katz、D。およびD. Ward、「IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）」、RFC 5881、DOI 10.17487 / RFC5881、2010年6月、<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>.
[RFC6793] Vohra、Q。およびE. Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<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>.
[RFC7454] Durand、J.、Pepelnjak、I。、およびG. Doering、「BGP Operations and Security」、BCP 194、RFC 7454、DOI 10.17487 / RFC7454、2015年2月、<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>.
[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>。
Acknowledgments
謝辞
The authors would like to thank Chris Hall, Ryan Bickhart, Steven Bakker, and Eduardo Ascenco Reis for their valuable input.
著者は、貴重な情報を提供してくれたChris Hall、Ryan Bickhart、Steven Bakker、およびEduardo Ascenco Reisに感謝します。
Authors' Addresses
著者のアドレス
Nick Hilliard INEX 4027 Kingswood Road Dublin 24 Ireland
Nick Hilliard INEX 4027 Kingswood Roadダブリン24アイルランド
Email: nick@inex.ie
Elisa Jasinska BigWave IT ul. Skawinska 27/7 Krakow, MP 31-066 Poland
Elisa Jasinska BigWave IT ul。 Skawinska 27/7クラクフ、MP 31-066ポーランド
Email: elisa@bigwaveit.org
Robert Raszuk Bloomberg LP 731 Lexington Ave. New York, NY 10022 United States of America
Robert Raszuk Bloomberg LP 731 Lexington Ave. New York、NY 10022アメリカ合衆国
Email: robert@raszuk.net
Niels Bakker Akamai Technologies B.V. Kingsfordweg 151 Amsterdam 1043 GR Netherlands
Niels Bakker Akamai Technologies B.V. Kingsfordweg 151アムステルダム1043 GRオランダ
Email: nbakker@akamai.com