RIPE Routing Working Group Recommendations on Route Aggregation
翻訳文

社団法人日本ネットワークインフォメーションセンター
最終更新 2010年12月1日

この文書は
http://www.ripe.net/docs/ripe-399.html
を翻訳したものです。
JPNICはこの翻訳を参考のために提供しますが、その品質に責任を負いません。

RIPE ルーティングワーキンググループによる経路集約(Route Aggregation)に関する推奨

Philip Smith
Rob Evans
Mike Hughes

文書 ID: ripe-399
日付: 2006年12月

概要

本書は、現在のインターネットにおけるプリフィクスの集約(aggregation) の必要性について論じており、インターネットサービスプロバイダーおよびインターネットに接続したその他の自律ネットワークに対して、好ましい運用を推奨している。

1. はじめに
2. 背景
- 2.1 初期のインターネット
- 2.2 現在のインターネット
3. 集約(aggregation)とは何か?
4. インターネットルーティングテーブル
5. ルーティングテーブル肥大化への影響
6. 解決策
7. 推奨事項
8. 結論
9. 謝辞
Y. 参考文献
Z. 著者について

1. はじめに

インターネットは、相互に接続された自律ネットワーク(通常は自律システム(AS) と呼ばれる) から構成されている。これらの自律ネットワークは、これまで長期間にわたって、自らのネットワーク内部、またはその配下にある顧客ネットワークで使用する目的で、アドレス空間の割り振りまたは割り当てを受けてきた。このようなアドレス空間は、隣接する自律ネットワークに広告される。これらの隣接する自律ネットワーク間でのビジネス上、または契約上の取り決めにより、このアドレス空間を隣接する自律ネットワークに広告してもしなくてもよいことになっている。このような状態がインターネット全体にわたっている。

インターネットを構成している組織体から広告された、このようなアドレス空間の集合体は、インターネットルーティングテーブルと呼ばれている。

各ASが自分のアドレス空間を広告することによって、また各ASがそのような広告内容を直接的または間接的に習得することによって、インターネット内のそれぞれのエンドシステムは他のエンドシステムと通信ができるようになり、これによってインターネットというグローバルな通信システムが成り立っている。

2. 背景

CIDRレポート[1]やその他の同様の活動において記録されている通り、 1990年初頭に通信媒体としてインターネットが急速に普及した頃から、インターネットルーティングテーブルのサイズは、インターネットサービスプロバイダーやインターネットルーティング機器のベンダーにとってきわめて重要であった。

2.1 初期のインターネット

初期のインターネットでは、自律システムおよびエンドサイトに割り当てられるアドレス空間は、クラスA、クラスB、クラスCの3カテゴリーのいずれかに該当するものであった。インターネットルーティングテーブルは、これら3タイプのアドレスからのみ成り立っており、小さな組織がクラスC、中規模の組織がクラスB、大規模な組織がクラスAの分配を受けていた。このようなやり方は「クラスフルなアドレス割当」と呼ばれ、これに対応したルーティングシステムはこのようなクラスの違いを認識していた。

1994年にインターネットは大きな転機を迎え、クラスフルなプリフィクスシステムの利用からクラスレスのシステム利用へと移行が始まった([2] および [3])。この動機付けになったのは、クラスフルのアドレス空間が急速に枯渇しつつあり、特にクラスBネットワークに使われているアドレス空間の範囲 (128.0.0.0 から 191.255.0.0)がきわめて深刻な状況になっていたことだった。

クラスレスなアドレス管理システムに移行する前、インターネットの商業化が進むにつれてクラスCネットワーク以上の規模に成長した組織は、本来ならクラスBへ「アップグレード」されるはずだが、別のクラスCネットワークが与えられるようになった。これは、クラスBアドレスブロックの枯渇ペースを軽減するための施策であった。

この結果、多くの組織が、大量のクラスCアドレスブロック(現在の用語では複数の/24プリフィクス) を持つことになった。クラスレスルーティングシステムへの移行の一環として、 CIDR レポートは、ネットワーク事業者が複数の隣接する/24プリフィクスを一つの大きな広告に集約するように奨励するという意図を当初から持っていた。この活動は「集約(aggregation)」と呼ばれ、以後のセクションで詳しく説明する。

CIDR レポートは、集約(aggregation)の奨励で大きな成功を収めた。毎週、オペレーションに関わるメーリングリストへ投稿される公開電子メールにより、どこがインターネットへの広告において集約努力を行っている ISPであるのか着目させることにつながった。このような業界における社会的プレッシャーの成果は、 CIDRレポートのウェブサイト上で公開されているグラフの初期段階において見て取れる([1] および [4])。

2.2 現在のインターネット

現在のクラスレスインターネットでは、地域インターネットレジストリ(RIR) の仕組みに参加しているネットワーク事業者は、 RIR (AfriNIC, APNIC, ARIN, LACNIC & RIPE NCC) から割り振りを受ける。これらの割り振りは、ネットワーク事業者の要求条件に従ってRIRにより決定され、例えば/21を1ブロックなど、最小限のサイズになるのが通常である。

1994年にクラスレス割り振りシステムおよびクラスレスルーティングを導入して以来、ネットワーク事業者は、RIRからアドレスブロックを受け取り、このアドレスブロックをそのままインターネットに広告するはずであった。これは、初期のインターネットにおいて、事業者が割り当てられたクラスA、クラスB、またはクラスCをそのまま広告するのと同じである。

RIRから割り振られたアドレスブロックは、そのネットワーク事業者がそのままインターネットに広告するというのが、広く行き渡った暗黙の了解事項となっているにもかかわらず、現在いまだに/24(従来のクラスCと同等のもの) を広告することが一般的な運用上の慣行になっているように思われる。このため、インターネットルーティングテーブルの約60%は/24プリフィクスによって占められている。

/24広告の一部は、マルチホーミングによるトラフィックエンジニアリングの実現をめざしているものであることは、まちがいない。 (これは業界における必要な対応としてRFC1519 - [3] の著者からも認知されている活動である)。しかし多くの場合、 ISPが「RIRから32ブロックのクラスCを受け取った」と認識し、それに基づいて広告することが原因である。 (本来、これらはネットワークマスクを /19とした単一の広告にまとめることが求められる)。

3. 集約(aggregation)とは何か?

集約(aggregation)とは、複数の隣接するIPアドレスを(BGPを使って) 単一のアドレスブロックにまとめて IPルーティングシステムに反映する活動のことである。例えば、ある企業が社内LAN上のシステムに番号を付与するために、 ISPから32個のIPアドレスを取得した場合、その企業はこれら32個のIPアドレスを一つの独立体(entity) としてISPに広告する。 LAN上の各デバイスは、外部に向かって、その存在を個別に示さなくとも、全体をまとめたアドレスブロックとして表現することができる。

例えば、企業が192.0.2.0 から 192.0.2.31 までの連続するIPアドレスを取得した場合、彼らはこれを192.0.2.0/27 としてISPに広告する。このフォーマットは、IPアドレスの最初の27ビットがネットワーク部分であり、最後の5ビットがホスト部分であることを意味する。

より規模の大きな場合でも同様であり、例えばISPが10.201.48.0 から 10.201.63.255までの4,096 の IPアドレスをRIRから取得したとすると、そのISPはそれらのIPアドレスを一つのアドレスブロックとして、すなわち10.201.48.0/20として隣接ネットワークに広告することになる。

これらの二つの例は、集約(aggregation)がどのようなものかを示している。末端にあるネットワークは、連続アドレスを一つの独立体(entity)としてまとめ、この単一の独立体(entity)が隣接する自律システムに広告される。

この二つの例は、比較的小規模な例ではあるが、インターネットに参加しているISPの活動を示している。すなわち、個々のIPアドレスは、インターネットに広告される前に、より大きくて扱いやすいブロックにまとめられるのである。

代理の集約(proxy aggregation)とは、あるISPが、他のネットワークから(通常BGPを使って) 連続したプリフィクスブロックを受け取ったとき、それらを一つのより大きな広告にまとめ、それを自分のネットワークからの広告として出し直すことを意味する。

4. インターネットルーティングテーブル

インターネットルーティングテーブルのサイズを増やす要因はいくつか存在する。それらを以下に分析する。

4.1 細分化(deaggregation)とは何か?

RIRはブロック単位でアドレス空間をISPに割り振るにあたって、それらのブロックが変更されず、そのままインターネットに広告されることを期待している。しかし、このアドレス空間がどのようにインターネットに広告すべきかについて、 RIRで定めたルールはないことに注意されたい。業界としては、 RIRからアドレス空間の広告方法を指示されるのは不適切だと見なしている。それは、図書館が、貸した本をどのように読むべきかを借り手に指示しないのと同じである。

しかし、多くのISPは、自分たちへの割り振りを、期待通りの単一ブロックとして広告せず、時には/24まで細かく分割して自分たちのアドレス空間を広告することを選択している。このような行為を細分化(deaggregation)と呼んでいる。

4.2 一般的な細分化(deaggregation)

このような細分化(deaggregation)が行われる理由はいくつかあると思われる。このような行為にはビジネス上の理由があると主張するプロバイダーもいれば、ルーティングシステムのセキュリティ上の懸念があることを引き合いに出すプロバイダーや、これによって帯域を浪費するウィルスや自らのネットワークに害を与える悪意の行為を減らすことができると主張するプロバイダーもいる。

ルーティングシステムのセキュリティは、インターネットに関わる多くのプロバイダーにとって共通の関心事項である。プロバイダーから発信されたアドレスブロックを正しいものとして保障する仕組みとして、一般的に受け入れられている、または利用されているものはない。 (インターネットルーティングレジストリは、これを助成するように設計されたが、利用は強制されておらず、なくてもルーティングシステムは十分に機能する)。この結果、一部のプロバイダーは、プリフィクスをできるかぎり小さい単位で広告することで、ルーティングシステムのセキュリティ不足を埋め合わせようとするようになった。これにより、他の自律システムからは同じプリフィクスに対し、それ以上に小さな範囲で広告を行うことはできず、アドレス空間の正しいユーザーがサービスの妨害を受ける可能性がなくなる。しかし著者には、そのような事件はほとんど記録されていないことを知っており、従ってセキュリティを理由にした細分化(deaggregation)は、潜在的なリスクと比較すると、過剰に非友好的な行為のように思われる。

細分化(deaggregation)のもう一つの理由として、サービスプロバイダーのネットワークに的を絞った Dos攻撃(サービス妨害攻撃) や悪意のある行為を減らすということが主張されている。インターネットの世界では、 (ルーティングされているかどうかに関わらず)ウィルスやワームに感染して、他のシステムを感染させようと、連続したアドレスブロックを単純にスキャンするシステムがたくさん存在するのは周知の事実である。これは、あるアドレスブロックに対するトラフィックの「バックグラウンドノイズ(雑音)」となる。著者の経験によると、一つの/16アドレスを広告すると、このような雑音を最大で2Mbpsも引き寄せる可能性がある。インターネットが発展途上にあるような地域では、このような帯域はISPにとって非常にコストがかかるので、彼らは実際に使っているものだけしか広告しない。 /24が自分たちのインフラまたは顧客によって消費され尽くすと、彼らは新しい/24をインターネットに広告する (また、このような/24は、最初に行われた内部での割り振りの順序通りにならないことが多い)。元々の/19割当がすべて使われ尽くした時でさえ、 ISPは集約(aggregation)を行おうとせず (彼らから見れば、何らかの故障が発生しているわけではないので、解決する必要はない)、この結果としてグローバルなルーティングテーブルのサイズの肥大化を引き起こしている。

一部のプロバイダーが「我々には細分化(deaggregation)をやるだけのビジネス上の理由がある」と主張する場合、上記の両方のシナリオを懸念しているようである。他にも商業的な理由が存在する可能性は非常に高い。例えば、近年耳にした例では、CIDRレポートのトップ10に登場すると、 ISPのビジネスの規模や品質が良いことの証であると肯定的に受け取られることがあるようだ。

4.3 iBGP と eBGP

さらに細分化(deaggregation)の別の理由として、サービスプロバイダーネットワークの内部で使用されるBGP(iBGP)と、ドメイン間のルーティングに使われるBGP(eBGP) との違いを認識していないことが挙げられる。 iBGPの目的は、 ISPの顧客のプリフィクスやローカルなインフラのプリフィクス (ホスティングLANなど)、および他のサービスプロバイダーネットワークから習得したプリフィクスなどをすべて広告することである。これに対してeBGPの目的は、ドメイン間の到達可能性を広告することであり、 RIRから割り振られたアドレスブロックを各ISPがそのまま広告するだけで、この目的は達成できる。 ISPが何も考えずにiBGPルーティング情報を eBGPに入れてしまうことが非常に多く、これによってインターネットルーティングテーブルが肥大化するという結果を招いている。

おそらく、 ISPのiBGP と eBGPとの違いを最もよく示している非常に興味深いサイトは、オレゴン大学のRoute Viewsプロジェクトであろう[5]。このプロジェクトは、世界各国のISPから、実際に見えている通りにインターネットルーティングテーブルの表示内容 (view)を提供している。 eBGPの経路情報を送信するISPもいれば、 iBGPの経路情報を送信するISPもいる。このRoute Viewsプロジェクトでは、何を送信すべきか、何を送信すべきでないかの要求は行っていない。このため、このプロジェクトは、 ISPが集約(aggregation)を行う際に非常に参考になり、一部の大手ISPはiBGPの範囲が理解でき、他のISPはインターネットルーティングインフラを通してピアから受け取った iBGPの内容にフィルタをかけて除去することができる。

4.4 マルチホーミングを目的とした細分化(deaggregation)

マルチホーミングを実施しているネットワークは、トラフィックエンジニアリング的な業務の一環として細分化(deaggregation) を実施する必要があることを度々言い訳にするか、またはそれによってインターネットルーティングテーブルが肥大化しても仕方ないと完全に割り切っている。最近のマルチホーミング手法は、アドレスの割り振りまたは割当を受け取ると、それを/24単位に分割し、小間切れになった/24を外部のネットワークリンクに広告するというのが一般的になっているようだ。

このような業務で/24が選ばれているのは、ほとんどのISPが/24(既存のクラスCアドレスのサイズに相当する) を境界としてIPプリフィクスにフィルタをかけると信じ込んでいるためであるが、 CIDRレポート[1]を少し眺めただけで判る通り、そのような思いこみを裏付けるような証拠はほとんど存在しない。

さらに、アドレスブロックを/24単位でしか広告しない背景には、こうするとマルチホーミングがうまくいくという持論を持っているためでもある。しかし、著者の経験では、これは間違いである。トラフィックエンジニアリングや負荷バランスを成功させるためには、割り振られたアドレスブロック内の適切なサブプリフィクスを、それらのサブプリフィクスを占有しているデバイスから発生するトラフィックの程度に応じて広告することしかない。

このような散弾銃方式の結果、インターネットルーティングテーブルのサイズはますます肥大化することになる。

4.5 歴史的経緯をもつ割り当て

インターネットルーティングテーブル肥大化の原因として、よく非難を浴びるのが従来の歴史的経緯を持つ割り当てである。これは、RIRシステムが確立する前にIANAが行った割り当てのことを指している。しかし、従来の割り当てが主にインターネットルーティングテーブルに入ってきたのは、 192/8ブロック、すなわち以前のクラスC空間の最初の/8ブロックであった。クラスレスルーティングへの移行後にクリーニングを行ったため (多くの事業者が自分たちのクラスフルアドレスをできるかぎり集約した)、 192/8アドレスは、インターネットルーティングテーブルに約5,500のプリフィクスを残すのみとなった。 RIRがISPへの割り振りで使ったその他の/8プリフィクスでは、割り振りが完了したブロック一つ当たり8000または9000のプリフィクスが入れられているので、これと比較すると、上記の数字は非常に素晴らしい成果だと言える。

以前のクラスB空間(128/8から191/8まで)を見てみると、既存のクラスB割当で細分化(deaggregation)が顕著であるが、これは前の2セクションで論じた問題点によって引き起こされている可能性が高い。以前のクラスA空間における既存割当も同様である。

5. ルーティングテーブル肥大化への影響

インターネットルーティングテーブルのサイズは、なぜ重要なのか？これまでの議論では、何をインターネットへ広告すべきかについて、かなり率直な意見を述べてきた。しかし、今日インターネットに参加している自律システムはさまざまな課題を抱えていることも事実である。

5.1 ルータのメモリ

インターネットの歴史が始まってからずっと、ルーティング装置のベンダーは、その時点でのネットワークに合わせてルーティング装置の仕様を決めてきた。しかし、インターネットが急速に普及したため、このことが、さまざまな段階において事業者を苦しめる結果となっている。インターネットの急拡大により、ある年にテーブル全体に対応できるくらい十分なメモリをルータが持っていたとしても、翌年には不十分になっていた。ルータを最大記憶容量までアップグレードしたとしても、テーブル全部を格納するだけの十分な容量に到達しないという事態も発生していた。

これに対処するため、より大きなメモリを持つ新しいモデルのルータにリプレースしなければならず、これによってルータは、他のインターネット機器に比較して在庫寿命が非常に短くなった。このように頻繁な機器リプレースを行ったため、サービスプロバイダーのネットワークが大混乱になる結果を招いた。

5.2 ルータの処理能力

問題となっているもう一つのリソースが、ルータのCPU(制御プレーン)である。インターネットルーティングテーブルのサイズが大きくなればなるほど、隣接する自律システムとのBGPセッションを最初に設定する時にルータ CPUの処理時間が長くなり、トポロジーの変化に伴うルーティングテーブルの変更を処理するのにルータ CPUが要する時間も長くなる。より高速のCPUを使えばこの時間を短くできるので、ネットワーク事業者はルータ CPUをアップグレードしなければならないという事態に直面し、自社のルーティング性能を維持するという目的のためだけに大がかりなアップグレード (シャーシ全部を入れ替える)を行うことが少なくない。

5年後に必要となるルータのサイズを予測してほしいという要望に応えて、一般的なシナリオが[6]に示されている。テーブルのサイズが肥大化し、インターネット上でルーティング情報の更新回数が増えるにつれ、既存ルータハードウェアの在庫寿命は短くなっている。

5.3 ルーティングのコンバージェンス

ルーティングのコンバージェンス(収束)とは、特定の接続先に最も良いPATHを算出し終わった時のことを指す。経路が取り消される、または広告が出し直されるたびに、コンバージェンスが必要となる。この計算には時間がかかる。

ルーティングのコンバージェンスにかかる時間は、主にルータのCPUとルーティングテーブルのサイズという二つの要素によって影響を受ける。インターネットルーティングテーブルにプリフィクスが多ければ多いほど、新しいルートを見つけだすためにルータがやらなければならない作業量が増える。この時間は、より高速のCPUを使うことで減らせるが、制御プレーン(control plane)のアップグレードは通常、コストと負荷を伴う。ルータのシャーシ全部を入れ替えることは (いわゆるフォークリフト・アップグレードと呼ばれているもの)、ネットワークのダウンタイムによる影響は言うに及ばず、事業者に多大なコストがかかる。コンバージェンスの問題を解決するためのもう一つの方法は、プリフィクスの集約(aggregation)を行ってできるだけ広告数を少なくし、インターネットルーティングテーブルのサイズを減らすことである。

コンバージェンスが遅いと、ネットワーク障害からの復旧時間も遅くなり、ネットワークの問題点が顧客に見えやすくなることを意味する。

5.4 ネットワークのパフォーマンス

ネットワーク事業者は、ネットワークのパフォーマンスとインターネットへのプリフィクス広告とは無関係であると見なしている。

しかし、集約(aggregation)を行って広告した場合に比べて、集約(aggregation)をせずに広告した場合、ローカルネットワークのエンドユーザーが経験する全体的なインターネットの使い心地が劣ることは、比較的簡単に実証できる。

著者がこれまでよく経験した典型的な例としては、ネットワーク事業者が内部BGPのプリフィクスをインターネットに (外部BGPで)広告してしまうというケースである。顧客とのリンクがアクティブ状態の時には、顧客のプリフィクスが内部のBGPに注入され、顧客とのリンクが非アクティブ状態になるとそれらは取り消される。内部BGPがインターネットに流れてしまうと、インターネット全体にわたって、フル記載のインターネットルーティングテーブルを保持するすべてのルータから、これらのプリフィクスを取り消さなければならないという問題が生じる。このような取り消しは、瞬時に終了するわけではなく[7]、均質に実行されるわけではないので、これによって付帯的な問題が発生する。顧客のリンクがアクティブ状態に戻ると、顧客のプリフィクスがプロバイダーの内部BGPに再び注入され、さらにインターネットに広告される。この場合も、アウトバウンド広告の伝搬は瞬時に完了するわけではない。

上記の結果として、エンドユーザーがリンクをアクティブ状態にしても、インターネットがすぐに使えなくなる。サービスプロバイダーに連絡しても、サービスプロバイダー側では何の問題もないように思えるので、この問題が解決するわけではない。

サービスプロバイダーが内部BGPをインターネットに流さず、代わりに集約(aggregation)を行い、トラフィックエンジニアリング上必要なサブプリフィクスを広告していたならば、顧客は、インターネット接続がすぐに使えないという現象を経験することはなかったであろう。

6. 解決策

近年、インターネットルーティングテーブル肥大化の問題を解決するためのさまざまな方法が提案され、試行されてきた。

6.1 CIDR レポート

CIDRレポートは当初、インターネット経路の拡大を抑制する技法の一つであった。 CIDRレポートの目的はISPによる集約(aggregation)の奨励であった。その有効性は、主に業界内における社会的プレッシャーおよび実名の掲載による名指し効果により成り立っていた。これはインターネットがクラスフルからクラスレスへと移行する初期段階においては有効であったが、近年では、 CIDRレポートで目立っていることはインターネット業界でのステータスと影響力を示すものとして、逆にこれを利用するISPがいるようである。

近年、CIDRレポートは初期のレポートツールから大幅な拡張が行われ、そのウェブサイト[1]はネットワーク事業者が自らの集約 (aggregation)活動の効果を確認できるユーザーインタフェースを持っている。また、CIDRレポートは、特定のASNのルーティングテーブルの表示内容を採取し、どのような集約(aggregation)が可能かを助言するツールも持っている。ネットワーク事業者がインターネットのルーティングテーブルへの自分らの広告に気づかないでいる要因は少なく、集約に向けた改善方法がわからないということも、基本的には言い訳にはならない。

6.2 フィルタリング

もう一つの技法としては、IANAがRIRに割り振ったアドレスブロックごとに、 RIRの最小割り振りサイズでフィルタをかけるというテクニックが利用されている。例えば、あるRIRにおいて、特定の/8ブロックからの最小割り振り単位が/21であったとすると、ネットワーク事業者は、外部ネットワークから受け取るルーティング広告にフィルタをかけて、 /21より小さなプリフィクスは拒絶する。これによってもたらされる好ましい成果の一つとして、事業者は、これらのフィルタを切り抜けるために、より大きなプリフィクス(さらには集約したブロック)を広告する。

一般的なフィルタリングの効果は、 CIDRレポートのウェブサイト[4]から、さまざまな自律システムから見たインターネットルーティングテーブル全体の表示内容を見ることができる。

RIRの最小割り振りサイズでフィルタをかけているネットワーク事業者がどれくらいいるかはわかっておらず、このようなフィルタリングがルーティングテーブルのサイズを制限するという当初の目的を達成できるくらい有用なものかどうかも明瞭ではない。非常にはっきりしているのは、ネットワーク事業者がRIRから最小割り振りサイズを受け取っていた場合、マルチホーミングを実施するためのトラフィックエンジニアリング能力はある程度制限される。なぜなら、上流のプロバイダーがRIR最小割り振りサイズの境界でフィルタをかけていれば、トラフィックエンジニアリングの目的のためにアドレスブロックを細分化することができないからである。

6.3 CIDR ポリス

1990年代後半から2000年代初頭にかけて、小さなボランティアグループがさまざまなルーティングテーブルの広告レポートを分析し、必要以上に多くのプリフィクスを広告しているISPに対して、無報酬で働き掛けていた[8]。彼らは、連続する/24プリフィクスを広告しているISPを探し、これらを一つのより大きな広告に集約すればインターネットルーティングテーブルにとって有益であると助言した。この成功の程度はさまざまであり、当該ネットワーク事業者から協力を得たり、感謝されたりすることもあれば、彼らから敵視または悪意を持った対応をされることすらあった。

2001年にインターネットバブルが崩壊した時、「CIDRポリス」の活動を支えていたボランティア達は、彼らの目の前にある他の優先課題に取り組むようになった。近年、「CIDRポリス」活動を再開しようという議論がなされているが、本書を執筆している時点では、まだ何も具体的なことは決まっていない。

6.4 BGP の機能

インターネットコミュニティ(主にISPと機器ベンダーによる)も、集約(aggregation)努力を支援するため、 BGPにおける機能の追加に取り組んできた。以下にそれを説明する。

6.4.1 NO_EXPORT BGP コミュニティ

マルチホーミングおよびプリフィクスの集約 (aggregation)への最初の支援策は、 BGPコミュニティ属性仕様[9]の一部として記載されている _EXPORT BGPコミュニティとしていうかたちをとっていた。このコミュニティがタグ付けされたプリフィクスは、 eBGPルータから別のルータへと広告することができなくなる。

すなわち、サービスプロバイダーがトラフィックエンジニアリング目的のためにサブプリフィクスを上流またはピアのプロバイダーに流す時に、これらのプリフィクスに"no_export"コミュニティのタグを付けておけば、これらのサブプリフィクスを他の自律システムに広告しないように上流プロバイダーに要請できる。多くのプロバイダーがトラフィックエンジニアリング上の目的のためにこのコミュニティを使っているが、普及の程度は、本来あるべき姿よりずっと少ないようである。

6.4.2 The NOPEER BGP コミュニティ

トラフィックエンジニアリングおよび集約 (aggregation)の難問を解決する次の支援策はNOPEER BGPコミュニティであった。これが導入されたのは比較的最近であり[10]、まだ機器ベンダーからサポートされておらず (それを実現した機器はないようである)、インターネットサービスプロバイダーからサポートを要望する声もほとんどない。

これは、マルチホーミングによるトラフィックエンジニアリング目的で、細分化(deaggregation)(細分化)行いたいサービスプロバイダーは、そのような「トラフィックエンジニアリング」サブプリフィクスに NOPEERコミュニティをタグ付けするとの考えに基づいてる。上流のISPは、そのeBGP関係がピアと見なされるかどうかに応じて、それらのプリフィクスを伝搬するか廃棄するかを決定する。

一般にインターネットサービスプロバイダーは、 3タイプの関係性(上流、相互的ピア、カスタマー) でインターネット上の他のプロバイダーと接続している。プロバイダーがNOPEERコミュニティをサポートするためには、そのルータ構成において、BGPのピアリングが上流か、相互的ピアか、カスタマーかを明示する。上流とカスタマーのBGPペアリングは、 NOPEERがタグ付けされたプリフィクスをピアリングで伝搬するのに対して、相互的ピアでは、NOPEERがタグ付けされたプリフィクスは廃棄される。これにより、末端側にいるプロバイダーは、「インターネットコア」にまでトラフィックエンジニアリング的方策を実施でき、「インターネットコア」は、そのようなトラフィックエンジニアリング的方策に必要なサブプリフィクスを運搬する必要がない。

インターネットの中核部分では、相互に無償でペアリング関係を結んでいるサービスプロバイダーが 10社ほどあると推定されており[11]、インターネットの大多数の ASNは転送の中心部分ではなく末端部分に存在しているので、それらの末端プロバイダーが、転送の中心部分に対する付帯的な機能を持ったNOPEERコミュニティを使えば、「インターネットコア」におけるルーティングテーブルのサイズに著しい影響を与えることができるはずである。

6.4.3 AS_PATHLIMIT 属性

マルチホーミングを実施する ISPのトラフィックエンジニアリング的ニーズに応えるものとして、最も新しく導入が提案されているのが AS_PATHLIMIT属性である[12]。

このアイデアは、AS_PATHLIMIT属性の値を使うことで、あるプリフィクスの伝搬範囲を特定のASの半径内に制限しようというものである。この属性は、AS PATHで可能な最大ASN数を指定する (この属性を発信したASNもこの数に含まれる)。それぞれのASは、AS_PATHにあるASNの数と属性の値とを比較する。 AS_PATHにあるASNの数がAS_PATHLIMITで指定された値を上回ったら、そのプリフィクスはネットワーク内部で処理されなくなるか、またはeBGPペアへの伝搬も行われなくなる。これにより、サービスプロバイダーは、トラフィックエンジニアリング的方策をローカルに実施し、インターネットの遠隔地にある他のプロバイダーは、これらの特殊なトラフィックエンジニアリング的プリフィクスを取り扱わなくてすむようになる。

6.4.4 プロバイダー固有のコミュニティ

多くの転送プロバイダーは、自らの顧客向けに、 NO_EXPORTより広いプリフィクス伝搬範囲を持っているがグローバルなルーティングテーブルに入ることは許容されないようなBGPコミュニティを提供している。多くの場合、これには、「地域内のすべてのピア」、「すべてのピア」(ただし彼らの転送プロバイダーは含まれない)、場合によっては顧客がマルチホーミングになっているような特殊なピアだけといったオプションを付けることができる。

プロバイダー固有のコミュニティは、そのプロバイダーのウェブサイトか、時にはインターネットルーティングレジストリのシステム内にある「ルートオブジェクト」の一部に記載されているのが普通である。コミュニティの値は、プロバイダー間で調整されているわけではないが、 1990年代半ばにInternetMCIが採用していたコミュニティ使用方法を記載した RFC1998 [13]の精神にのっとり、同様の値を使って同じ成果をあげようとしているISPがいくつか存在する。プロバイダー固有のコミュニティとしてよく知られている事例を [14]に記載する。

ルート伝搬はコミュニティの意図と一致する必要があるので、ルータ上のBGPポリシーが丹念に保守されるように配慮する必要がある。ルートが意図しない流れ方をすると、グローバルルーティングテーブルにまで伝搬し、この種の伝搬制限の意図が台無しになってしまう可能性がある。

7. 推奨事項

本書の最後として、RIPEルーティングワーキンググループがまとめた、インターネットへ経路広告を出す場合の推奨事項を記載する。すべてのネットワーク事業者がこれらの推奨事項を順守することで、インターネットルーティングレジストリの肥大化が抑制され、本当に必要なものだけが残されることが望まれる。

7.1 初期の割り振り

ネットワーク事業者がRIRからIPアドレスの割り振りを受ける、または上流ISPから割当を受けた場合、これらのIPアドレスを最大にまとめられるブロックに集約してインターネットで広告することが、全インターネットコミュニティからは期待される。

例えば、ネットワーク事業者がRIRから/21を取得した場合、隣接する自律システムにはこの/21だけが広告されるようにBGPを設定すべきである。

7.2 追加的な割り振り

RIRそのLIRメンバーに割り振りを行う場合、可能な限り、以前の割り振りと連続したものを分配するよう試みる。ネットワーク事業者が、前の割り振りと同じサイズで連続したブロックを、新しい割り振りまたは割当として取得した場合、彼らはこの二つのアドレスブロックをまとめ、一つの集約ブロックとして広告すべきである。

例えば、ネットワーク事業者が以前に/21の割り振りを受けており、それと隣接する/21を新しく受けたとしよう。これら二つの/21がビット境界で一致するのであれば、これは一つの/20にまとめることができる。従って、彼らはこの/20を隣接ASNに広告し、以前の/21の広告を削除すべきである。

追加的な割り振りで与えられたブロックが連続していない場合、または連続ではあるがビット境界が衝突する場合、または以前の割り振りとサイズが異なっている場合は実施すべき集約 (aggregation)はなく、ネットワーク事業者は二つのアドレスブロックを別々に広告すべきである。

7.3 マルチホーミング

ネットワーク事業者がマルチホーミングされたネットワークを持っている場合、トラフィックエンジニアリングを実施しやすくするために、一つまたは複数のアドレスブロックを分割する必要性に迫られることがある。事業者がこれを実施する必要がある場合でも、元のアドレスブロックとして広告を出さなければならない。なぜなら、このように広告を出していないと、代替リンクが障害になった時に予備リンクがなくなるからである。このようなアドレスブロックの分割は慎重に行うべきである。ここ数年、各種ネットワーク運用フォーラムでチュートリアルが設けられ、インターネットルーティングテーブルに悪影響を及ぼさずにトラフィックエンジニアリングの効果を最大化するにはどのようにすればよいかを説明を行っている[15]。

7.4 BGP強化策

セクション6.4で説明した各種BGP強化策も、ルータのベンダーがサポートしていれば、適宜検討すべきである。転送コアの外部にいるほとんどのISPは、 NO_EXPORTやNOPEER BGPのコミュニティおよび新しいAS_PATHLIMIT BGP属性を導入して、インターネットへ伝搬するトラフィックエンジニアリング関連サブプリフィクスの数を制限することができるはずである。

7.5 代理の集約(proxy aggregation)

代理の集約(proxy aggregation)は、きわめて慎重に取り扱う必要がある。他のAS番号から発信されている広告を集約してしまうと、望ましくない結果を招く恐れがある。特に他のAS番号が実施しているトラフィックエンジニアリングや、リンク障害時のトラフィックの「ブラックホール」化などへの悪影響がある。集約(aggregation)によって関連するネットワークの運用に支障がでないこと (例えば、関連ネットワークが同じ上流のプロバイダーだけでマルチホーム化されていること) をネットワーク事業者が十分に確認した場合にのみ、代理の集約(proxy aggregation)は効果を発揮する。

以上