Loading article…
ソース固有ルーティング[1]は、ソースアドレス依存ルーティング（SADR）[2]とも呼ばれ、パケットの送信元アドレスと宛先アドレスを参照してルーティングを決定するルーティング技術です。ソース固有ルーティングの主な用途は、プロバイダーに依存しないアドレスや上流ISPの協力を必要とせずに、安価なマルチホーミングを可能にすることです。
問題
従来のネクストホップ ルーティングでは、パケットは宛先のみに従って、その宛先に一致するルートを通知する最も近いルータに向かってルーティングされます。 2 つの ISP (BT&T と PacketCast) に接続されたマルチホーム エンドユーザー ネットワークを考えてみましょう。このようなネットワークには通常、それぞれが 1 つの ISP に接続された 2 つのエッジ ルータがあります。
両方のエッジルータはデフォルトルートをアナウンスします。これは、インターネット宛のパケットを受け入れる意思があることを意味します。BT&Tネットワークから送信されたパケットがPacketCastのエッジルータを経由してルーティングされた場合、PacketCastはそれを偽装パケットと見なし、BCP 38に従ってそれをドロップします。[3]
ソース固有のルーティングによるマルチホーミング
ソース固有のルーティングでは、各エッジ ルータがソース固有のデフォルト ルートをアナウンスします。これは、インターネット宛てのパケットに適用されるルートですが、その送信元が特定のプレフィックス内にある場合に限ります。その結果、各エッジ ルータは、そのプロバイダーのプレフィックス内に送信元アドレスを持つパケットのみを引き寄せることになります。
望ましいホストの変更
ソース固有のルーティングでは、各ホストインターフェースには、プロバイダー依存のプレフィックスごとに1つずつ、複数のアドレスがあります。送信トラフィックの場合、ホストソフトウェアは正しい送信元アドレスを選択する必要があります。これを行うためのさまざまな手法が提案されており、ネットワーク層で[4] 、ネットワーク層より上( Shim6を参照)、または上位層でマルチパス技術を使用する( Multipath TCPおよびMultipath Mosh [5]を参照)などです。
ルーティングプロトコルのサポート
エッジルータが1つのネットワークでは、ルーティングテーブルを手動で操作することでソース固有のルーティングを実装できます。[6] ルータが複数ある場合は、ルーティングプロトコルでソース固有のルーティングを明示的にサポートする必要があります。
2016 年初頭現在、ソース固有のルーティングのサポートを実装するルーティング プロトコルは 2 つあります。
- Babelルーティングプロトコルは、 IPv4とIPv6の両方でソース固有のルーティングをサポートしています。[7]これは、babeldとBIRDでIPv6用に実装されています（ babeldの以前のバージョンでは、IPv4のソース固有のルーティングをサポートしていました[8]）。
- IPv6のみのソース固有ルーティングをサポートするIS-ISの実装が存在する。 [9]
IETF Homenetプロトコルスイートでは、ルーティングプロトコルにおいてソース固有のルーティングのサポートが求められています。[10]
参考文献
- ^ Matthieu Boutier、Juliusz Chroboczek ( 2015)。ソース固有のルーティング。Proc . IFIP Networking 2015。arXiv : 1403.0445。Bibcode : 2014arXiv1403.0445B。
- ^ “ドラフト-トロアン-ホームネット-sadr-01”.
- ^ RFC 2827
- ^ RFC 6724
- ^ Matthieu Boutier、Juliusz Chroboczek (2015)。「Mosh におけるユーザー空間マルチパス UDP」。arXiv : 1502.02402 [ cs.NI]。
- ^ http://www.lartc.org/、セクション4.2
- ^ RFC 9079
- ^ 「[Babel-users] アナウンス: Babeld-1.10」.
- ^ 「Draft-baker-ipv6-isis-DST-SRC-routing-07」.
- ^ RFC 7368、セクション3.2.4