IPv6 ネットワークにおける エニーキャスト通信実現のための プロトコル設計と実装 宮原研究室の土居聡です。 「IPv6 ネットワークにおけるエニーキャスト通信実現のためのプロトコル設計と実装」というタイトルで 特別研究報告をさせて頂きます。よろしくお願いします。 宮原研究室 土居 聡

IPv4 から IPv6 へ アドレス空間の拡大 新たな機能の追加 32 ビット → 128 ビット セキュリティ リアルタイム通信 　新たな機能の追加 セキュリティ リアルタイム通信 移動端末のサポート アドレスタイプ アドレス設定の対象 通信形態 通信対象 ユニキャスト ノード 1 対 1 1 マルチキャスト グループ 1 対 多 多 エニーキャスト 機能 (サービス) 多 (その内の 1) まず本報告の背景として、IPv6 の概要を説明いたします。 IPv6 は IPv4 のアドレス枯渇問題を解決すべく策定された次世代インターネットプロトコルであり、 IPv6 ではアドレス空間は 128 ビットに拡大され、膨大な数の IP アドレスを割り当てることが可能です。 また、アドレス空間の拡大だけでなく、新たな時代の要求に応えるべく、セキュリティやリアルタイム通信、移動端末のサポートなどの新しい機能が追加されています。 この新たな機能の 1 つとして、エニーキャストアドレスがあります。

エニーキャストアドレス 機能（サービス）に対して割り当てられるアドレス 複数のインターフェースの集合を識別 グループのうち「最適な」インターフェースに配送 「最適さ」は経路制御機構によって決められる ミラーサーバなどでの利用 Anycast Membership エニーキャストアドレスは、これまでの IP アドレスと異なり、機能あるいはサービスに対して割り当てられるアドレスです。 そのため、同一の機能を提供する複数のノードに対して割り当てられます。 エニーキャストアドレス宛のパケットは、経路制御機構が、ホップ数、ノードの負荷などから決めた最適な 1 台に自動的に配送されます。 このような性質があるため、例えば、ミラーサーバでの利用が考えられます。ミラーサーバに対してエニーキャストアドレスを割り当てておけば、利用者は実際にどのサーバと通信するかを考えることなく、最適なサーバを選択し、通信を行うことができます。 最適な 1 台に 自動的に配送

エニーキャスト通信の性質 常に「最適な」ノードへとパケットを送信 エニーキャスト通信への要求事項 送信した複数のパケットが同じノードに届くとは限らない 1 パケットのみの送信には利用できる 1つのノードとの接続を続けることはできない エニーキャスト通信への要求事項 複数のパケットにより通信する場合 最初の 1 パケットで最適なノードが選ばれた後は同じノードと継続して通信を行いたい エニーキャスト通信は、 常に最適なノードへとパケットを送信するため、最初に送信したパケットとその次に送信したパケットが同じノードに届くとは限りません。このことから、1 パケットのみの送信には利用できますが、1 つのノードとの接続を続けることはできません。 ミラーサーバなどでの利用を想定すると、一般に 1 パケットのみで通信が終了することは考えにくく、1 つのノードと継続して通信を行う必要があるため、最初の 1 パケットで最適なノードが選ばれた後は同じノードと継続して通信を行いたいという要求があります。 既存の枠組みを変更する必要

研究の目的 既存のアプリケーションを修正することなくエニーキャスト通信を実現する ネットワークの状況に応じた動的な端末設定を実現する また、今後、エニーキャストアドレスを用いた通信を普及させるためには、既存の枠組みを変更することなく容易に移行できることが重要と考え、本報告では、既存の技術、アプリケーションを可能な限り修正することなくエニーキャスト通信を実現することを目的としています。 さらに、エニーキャスト通信のための経路制御機構についても考察し、ネットワークの状況に応じた動的な端末設定を実現することを目的としています。 本報告では、時間の都合上、エニーキャスト通信の設計に関する部分のみを説明されて頂きます。 後者につきましては、論文の方を参照して頂きますよう、よろしくお願いします。

Anycast Address Resolving Protocol (AARP) の提案 エニーキャストアドレスを最適なノードを調べるためだけに利用し、実際の通信はユニキャストアドレスに対して行う Anycast Address Resolving Protocol エニーキャストアドレスを対応するユニキャストアドレスへと変換するプロトコル 継続した通信を行えないというエニーキャスト通信特有の問題を解決するため、エニーキャストアドレスを通信開始時に、最適なノードを調べるためだけに用いて、実際の通信はユニキャストアドレスに対して行う、という手法を用います。 そこで本報告では、Anycast Address Resolving Protocol (AARP) という新たなプロトコルを提案します。 これは、通信開始時にエニーキャストアドレスを対応するユニキャストアドレスへと変換するプロトコルです。 ③ Unicast Address ② ① Anycast Address

AARP の実装方法 2 つの方式 中間ライブラリ (AARP ライブラリ) を作成し共有ライブラリを置き換える Client initiate プローブパケット方式 AARP をクライアント側で行う Server initiate piggyback 方式 AARP をサーバ側で行う 中間ライブラリ (AARP ライブラリ) を作成し共有ライブラリを置き換える 共有ライブラリのメカニズムを利用 既存のアプリケーションプログラムを修正することなくアプリケーションの挙動を変えることができる AARP の実装方法ですが、 AARP をクライアント側で行う、client initiate プローブパケット方式と、サーバ側で行う、server initiate piggyback 方式とがあります。 また、中間ライブラリを作成し共有ライブラリを置き換えるという方法をとります。 共有ライブラリとは、アプリケーション実行時に動的に呼び出されるライブラリなので、共有ライブラリ内の API を置き換えれば、アプリケーションプログラムに修正を加えることなく、アプリケーションの挙動を変えることができます。

Client initiate プローブパケット方式 クライアントがエニーキャストアドレス宛のプローブパケットを送出し、端末からの応答を受信することでユニキャストアドレスを取得する ① Aany 宛にプローブパケットを送信 ② ユニキャストアドレス Xuni を返す これは、クライアントがエニーキャスト宛にプローブパケットを送出し、それを受信した端末からの応答によって、エニーキャストアドレスに対するユニキャストアドレスを調べる方式です。 通常のユニキャスト通信とは、通信開始前にプローブパケットを送出する点が異なります。 ③ Xuni へ通信開始 Client Server Aany, Xuni

Server initiate piggyback 方式 ① Aany に対して通信開始 これは、サーバからの通信パケット上に、エニーキャストアドレスを付加させ、その付加情報からエニーキャストアドレスとユニキャストアドレスとを対応させる方法です。通信時のトランザクションはユニキャスト通信と同じですが、付加情報に対する挙動を各プロトコルに追加する必要があります。 ② 最初の返信パケット Aany piggyback ③ 以降はCuni と Xuni との通信 Client Server Cuni Aany, Xuni

両方式の比較 Client initiate プローブパケット方式を採用 Piggyback 方式 問題点 プローブパケットによるトラヒックが発生し、ネットワーク資源を消費してしまう アプリケーション層、トランスポート層のすべてのプロトコルを修正する必要がある 利点 実装が容易 トラヒック量はユニキャストと同じ ここで、両方式の問題点の比較を行います。 Client initiate － プローブパケット方式では、プローブパケットによってトラヒックが発生するため、ネットワーク資源を消費してしまう、通信開始までの時間が長くなってしまう、といった問題点があります。 一方、server initiate － piggyback 方式では、付加情報を扱うための修正が必要となるという問題点があります。 本報告では、既存の技術に修正を加えることなくエニーキャスト通信を実現することを目的としているため、プローブパケット方式を用います。この方式は、プローブパケットによるネットワーク資源の消費という問題点はありますが、これはアドレス解決のキャッシングを行うことにより軽減できます。また、プローブパケットには ICMPv6 Echo Request/Reply を用います。 Client initiate プローブパケット方式を採用 プローブパケット: ICMPv6 Echo Request/Reply

ICMPv6 Echo Request/Reply を用いたアドレス解決 エニーキャストアドレス宛に Echo Request を送出し、端末からの Echo Reply を受信することでユニキャストアドレスを取得する ① Aany 宛に Echo Request を送信 ② 送信元アドレス Xuni の Echo Reply Echo Request を受信したノードは 自身に割り当てられているユニキャストアドレスを送信元アドレスとした Echo Reply を返します。そのため、エニーキャストアドレスに対し Echo Request を送信すれば、返ってくる Echo Reply の送信元アドレスからエニーキャストアドレスに対応するユニキャストアドレスを得ることができるため、プローブパケットとしての条件を満たしています。 ③ Xuni へ通信開始 Client Destination Aany, Xuni

AARP ライブラリ Server Client Echo Request to AA AA query Application Echo Reply from UA AA AARP AARP Lib. to UA UA reply UA Socket IPv6 Network I/F AARP ライブラリは、図のように、アプリケーションスタックとソケットスタックとの間に位置しており、アプリケーションスタックで指定されたエニーキャストアドレスをユニキャストアドレスに変換し、ソケットスタックに渡します。 まず最初に、アプリケーション内で宛先アドレスを AA とした通信が開始されるとき、通信前に呼び出される API (例えば、TCP アプリケーションにおける connect()) によって、通常の共有ライブラリ上の関数ではなく、AARP ライブラリ上の関数が実行されます。 次に、 AARP ライブラリは、置き換えられた関数内で AARP によるアドレス解決を行います。 そして、AARP ライブラリは、得られたユニキャストアドレス UA を宛先として、本来の共有ライブラリの API を呼び出し、通常のユニキャストアドレスに対する通信と同様の処理を行います。 このように実装すれば、既存のアプリケーションに修正を加えることなく、エニーキャストアドレスを用いた通信を行うことができます。 AA : Anycast Address UA : Unicast Address

提案方式の評価 エニーキャスト通信の実現性を確認 FreeBSD 4.4 – Release 上で実装評価 TCP 通信の評価 telnet, ftp によるエニーキャストアドレスを割り当てたノードとの通信が実現できているかどうかの評価実験 UDP 通信の評価 DNS サーバにエニーキャストアドレスを割り当て、/etc/resolve.conf にそのエニーキャストアドレスを設定し、ホスト名解決が行われているかどうかの評価実験 本報告では提案した通信モデルを FreeBSD 上で実装し、評価実験を行いました。 実験対象として、TCP を利用したアプリケーションである telnet, ftp、UDP を利用したサービスである DNS を用いました。 まず、telnet, ftp ですが、エニーキャストアドレスに対して telnet, ftp を実行したときのパケットの送受信記録の観測を行いました。 どちらのアプリケーションも通信開始前にアドレス解決を行い、ユニキャストアドレスに対して通信を行っていることが確認できました。 次に、DNS ですが、DNS サーバにエニーキャストアドレスを割り当て、DNS サーバへのホスト名解決の問い合わせを行っているパケットの送受信記録を観測しました。その結果、DNS サーバのアドレス解決を行ってからホスト名解決の問い合わせを行っていることが確認できました。 (この、DNS でエニーキャスト通信が実現できたことは非常に大きな利点となります。というのは、世界中すべての DNS サーバに同一のエニーキャストアドレスを割り当てておけば、クライアント端末のオペレーティングシステム上であらかじめ DNS サーバのアドレスを設定することができるため、ネットワーク管理者が DNS サーバのアドレスを設定することなく、プラグアンドプレイで最適な DNS サーバを自動的に利用できるようになります。) エニーキャスト通信の実現性を確認

まとめと今後の課題 本報告のまとめ 今後の課題 エニーキャストアドレスの応用例と利用時の問題点に関する考察 エニーキャスト通信を実現するためのプロトコル設計と実装および評価 今後の課題 ICMPv6 Echo Request/Reply によるメッセージ量の把握 アドレス解決のキャッシングを行う場合のキャッシュの保持時間の検討 エニーキャストアドレスのための新たな経路制御機構 最後に本報告のまとめと今後の課題について述べさせていただきます。 まず、本報告では、エニーキャストアドレスの応用例を挙げ、またエニーキャストアドレスを用いた通信を行う際の問題点に関して考察しました。 次に、それらの問題を解決するための新たなプロトコル AARP の提案、実装、評価を行い、既存のアプリケーションを修正することなくエニーキャストアドレスを用いた通信が実現できる手法を示しました。 今後の課題としましては、 通信前に ICMPv6 Echo Request / Reply をやりとりすることによるメッセージ量の把握や、アドレス解決のキャッシングを行う場合のキャッシュの保持時間などの考察と、 エニーキャストアドレスのための新たな経路制御機構の確立を目指しております。 以上で特別研究報告を終わります。 ありがとうございました。