Protocols Design and Implementation for IPv6 Internet （ IPv6 インターネットに向けたプロトコルの設計と実装）

2002/2/22 博士論文最終試験 Protocols Design and Implementation for IPv6 Internet（IPv6インターネットに向けたプロトコルの設計と実装）大阪大学大学院基礎工学科情報数理系専攻ソフトウェア科学分野北村　浩

IPv6をめぐる背景 • IPv4のアドレス空間枯渇の問題に端を発し次世代のIP（IPng) の研究開発が1994年頃より本格化 • IETFにおける議論の末、IPv6をIPngとすることに決定 • IPv6の最大の特徴は 2128≒1038に及ぶ広大でグローバルな空間 • IPv6はIPv4のアドレス枯渇の問題を解決するだけでなく、IPv4の問題点を改善するとともに、新しい機能（Autoconfiguration やIPsec など）を提供 • IPv6は新たな通信分野 (移動端末、自動車、家電など）を開拓 • End-to-Endの通信が一般的になる • IPv6の基本機能は既に確立し、多くのOSで標準的にサポートを　開始(Solaris、FreeBSD、 NetBSD、Linux、WindowsXP など) • 既に100以上に及ぶsubTLA(商用IPv6アドレス)の申請があり、複数のISPによる商用IPv6 サービスが開始されている • IPv6は実験から実用のフェーズに入っており、IPv4からIPｖ６への移行は既に始まっている • IPv6はもう次世代のプロトコルではなく現世代のプロトコル

IPv6の未来とビジネス(公聴会のコメントを受けて)IPv6の未来とビジネス(公聴会のコメントを受けて) • IPv6の未来 • 普及は工学だけでなく、政治的要素が大きい • IPv4と違いIPv6ではグローバルな着信が可能となることが新しいサービスモデルを生む • 移動体端末のIPｖ6化が普及の原動力になる • IPv6のビジネスモデル • SOCKS-based IPv6/IPv4 Translator は • Client は Freeで配る • 高性能なServer製品を作り、そこで利益を上げる • アドレスが絶対的に足りない地域日本、欧州、中国あたりが有力市場

IPv6に向けて必要となる機能（発表の構成） • IPv4からIPv6へスムーズに移行する技術 • 移行の技術及び必要条件の分析 • 最小の制約でIPv6/IPv4相互通信を効率的に実現するSOCKS-based IPv6/IPv4 Translatorの設計と実装 • IPv6ならではの魅力的な新機能 • Hop-by-Hop Option機能を拡張 • 通信経路に沿って最小のコストでネットワークと通信装置の情報を実時間で効率的に取得し問題点やボトルネックを発見できるConnection/Link Status Investigation (CSI)の設計と実装 • Plug and Play機能強化と拡張 • プラグインしたIPv6ノードに自動的に論理ホスト名を設定し、Plug and Playでの通信やEnd-to-Endの通信の鍵となる技術Domain Name Auto-Registrationの設計と実装

IPv4からIPv6へスムーズに移行する技術 3種類の移行技術 • Dual Stack • IPv6とIPv4両方のプロトコルスタックを実装 • アドレス空間枯渇の問題を解決することができない • Tunneling • IPv4パケットへカプセル化してIPv6パケットを運ぶ • IPv4の海を越えてIPv6の陸地間の通信 • IPv6ノードはIPv4ノードと通信をすることができない • Translator • パケット及びプロトコルを変換する • 異種プロトコル間の相互通信を実現する • 移行初期から最終段階まで利用される技術 • （本質的解で本発表で取り上げる移行技術）

IPv4/IPv6 2重ネット 相手がIPv4ならIPv4相手がIPv6ならIPv6 S D Dual Stack • IPv6とIPv4両方のプロトコルスタックを実装 • アドレス空間枯渇の問題を解決することができない

IPv4ネット IPv6ネット IPv6ネット IPv4へカプセル化 R R S D IPv6 IPv6 トンネルの出入口 Tunneling(パケットのカプセル化) • IPv4パケットへカプセル化してIPv6パケットを運ぶ • IPv4の海を越えてIPv6の陸地間の通信 • IPv6ノードはIPv4ノードと通信をすることができない

IPv4ネット IPv6ネット T S D IPv6 IPv4 トランスレータ Translator(パケットの変換） • パケット及びプロトコルを変換する • 異種プロトコル間の相互通信を実現する • 移行初期から最終段階まで利用される技術（本質的解で本発表で取り上げる移行技術）

IPv6環境に移行するにあたっての変換技術に必要とされる条件IPv6環境に移行するにあたっての変換技術に必要とされる条件 • 現在IPv4で利用されている通信モデルでの使いやすさを保持すること • 既存の通信インフラとなるフレームワーク（DNSなど）を保持すること • 既存のIPv4用に作られたアプリケーションを全く修正することなくIPv4-IPv6間の相互通信に利用できること • 多様なIPv4及びIPv6サービスをサポートできること • スケーラブルで負荷分散に容易に対応できること

プロトコル変換の観点から必要とされる機能の分析プロトコル変換の観点から必要とされる機能の分析 • IP プロトコルの変換 • 各パケットのIP ヘッダの置き換え • 置き換えに利用する IP アドレス空間の予約 • アドレスマッピングに伴う複雑なアドレス空間管理 • IP に関連するプロトコルの変換 • IP に関連するプロトコル(例えば ICMP) の変換 • アプリケーション層でアドレス情報を交換するアプリケーション(例えば ftpなど) に対処する機能

ユーザ アプリケーションの観点から必要とされる機能の分析ユーザアプリケーション内部での手続き 1. 通信相手を論理的ホスト名であるFQDNで指定 2. FQDNから IP アドレスへ“DNS名前解決 API” を利用して解決して、その情報をコネクションを確立のために用いる FQDNが通信を開始する起点となる情報であり、 IPv4 及び IPv6に依存しない唯一の情報となっているスムーズな変換機能に必要で、キーとなる重要な技術はDNS 名前解決の機能をどのようにトランスレータ機能に取り込むか IPv4アドレスしか処理できない既存のアプリケーションでいかにしてIPv6を示すAAAA レコードを解決するか

機能を実装するプロトコル層による分類 基本機能はどのプロトコル層に実装するかで決定される • IP 層で実装(NAT 技術の応用) • IP ヘッダはIPv4とIPv6の間で透過的に(transparently)変換される • 変換されるコネクションは終端されない • “Transparent モデル” • アプリケーション層での実装(ALG firewall/proxy 技術の応用) IPv4 と IPv6 の二つのコネクションは一旦終端されリレーされる • ひとつは “Full-Termination モデル”ユーザは内部の変換トポロジーなどの構造を知る必要があり、手動で変換に必要な情報を設定する必要がある • もう一方は “Semi-Termination モデル”ユーザは内部の変換のための構造は基本的に知る必要がなく、変換に必要な情報は、特別なプロトコル（例えば SOCKSなど）を用いて内部で自動的に交換される

機能を実装するノード位置による分類 • Source ノードへの実装 • IPv4 アプリケーションはローカルに変換され、IPv6アプリケーションがそこにあるように振舞う • 長所: DNS 名前解決機能を変換機能の中に取り込める • 短所: そのノードにあるローカルアプリケーションしか変換対象にできない変換機能を全ての端末に実装する必要がある • Intermediateノードへの実装(一般的な利用法) • IP 層への実装　通信パス上のルータに実装: 各ノードのdefault route をそのルータに設定 • アプリケーション層への実装　サーバとして動作: サーバの位置を各ノードに設定 • 長所: ネットワーク上にいる全てのノードが変換機能を利用可能 • 短所: DNS 名前解決を変換機能に取り込むことができない • Destinationノードへの実装 • Source ノードに対して何ら制限を与えない • Dual Stack の方法に似ている　アドレス空間枯渇問題を解決できない

“Transparent モデル”　の特徴 • IP ヘッダの変換に集中パケットが届けば、変換できる. • Source ノードに対してなんら修正を必要としない • 致命的問題:DNS 名前解決機能を変換機能の中にとりこめないSource ノードは通信を開始することができない • 解: DNS の問い合わせパケットを置き換えるというスケーラブルではない多くの制限を伴う機構を使う必要がある • 基本的に正しく対応できなICMPv4 と ICMPv6の間の複雑なプロトコル変換を行う必要がある • 変換途中でパケット長が変わるので、性能劣化に直結するパケットのフラグメンテーションを起こす危険性がある • IPv6での新しい仕様(IPsec など)を利用することができない “Transparent モデル” は問題点が多い現在のネットワークフレームワークの柔軟性を欠く

“Full-Termination モデル” の特徴 • コネクションが一旦終端されてリレーされるため、”Transparent モデル“ のほとんど問題は解決される • 終端されるので、ICMPの変換は必要ない • パケットサイズはリレーされるそれぞれのコネクションで調整されるので、フラグメンテーションを起こす危険性はない • IPｖ６独自の新しい機能を容易かつ効率的に取り込める • 制限事項:ユーザは内部の変換トポロジーなどの構造を知り、手動で変換に必要な情報を設定する必要がある • もともと変換に必要な情報を転送できるような機能を持たないアプリケーションの場合は、このモデルは利用できない。

“Semi-Termination モデル” の特徴 • “Full-Termination モデル”の持つ問題は解決されている • 変換に必要な情報を自動的に内部で転送するために、新しいプロトコルと機構を導入する • Source ノードに新しい機能をインストールする必要がある • 新しい機能のインストールにより、 DNS 名前解決の機能をトランスレータ機能に取り込むことが可能 (このモデルの絶対的特徴でもある) “Semi-Termination モデル” が最適と判断SOCKS-based Translatorとして実現する

基本 Translator 機構 Client C Translator T Destination D Application Translator Application Same APIs to D Socks Lib to T to D Socket, DNS Socket, DNS Socket, DNS IPvX IPvX IPvY IPvY Network I/F Network I/F Network I/F Socksified Connection Normal Connection data data (control) to D

DNS名前解決の手続き(DNS Name Resolving Delegation and Address Mapping) DNS Server Application real IP 7 socket FQDN 6 1 3 gethostbyname2() getaddreinfo() Translator connect() FQDN real IP 2 socket fake IP FQDN 8 connect() fake IP 4 socket Socks Lib FQDN 5 socksified connection

DNS 名前解決の手続き(DNS Name Resolving Delegation and Address Mapping) • “FQDN” を引数としてDNS 名前解決を試みる • “fake IP” を返値として受け取る • “fake IP” を用いた“socket” を利用してコネクションを開設する • “fake IP”に対応する“FQDN”を変換テーブルから取り出す（この変換テーブルが実質的 Address Mapping) • “FQDN” をSOCKS化されたコネクションを通してTranslatorに伝える • Dual Stack であるTranslator において、通常のDNS Serverに問い合わせて、DNS 名前解決の委譲（DNS name resolving delegation）を実現する • “real IP” を受け取る • Translator上で “real IP” を用いて “socket” を作成し、Destinationに対してコネクションを張る

発展形 Translator 機構(Multiple Chained Relay) Client C Translator T1 Translator T2 Destination D Application Translator2 Application Translator1 Same APIs to D to D to T Socks Lib Socks Lib to T2 to T1 to S to D Socket, DNS Socket, DNS Socket, DNS Socket, DNS IPvY IPvZ IPvZ IPvX IPvX IPvY Network I/F Network I/F Network I/F Network I/F data data data (control) to D (control) to D Socksified Connection Socksified Connection Normal Connection

特徴 (1/2) • DNS に全く手を加える必要がない • Address map servers などというものは不要 • 変換のためのアドレス空間を予約する必要が全くない • アプリケーションに依存しない • 基本的にソケットとDNS名前解決APIを利用する全てのアプリケーションに対して利用できる • 例外: アプリケーション層でIPアドレス情報を交換するようなアプリケーション (例えば ftp PORT など) は例外となる • OS や NIC の種類に依存しない • UNIX も Windows どちらのOSも対象にしている • 物理的な NIC の種類に対する依存性はない • 必要な処理は簡単な SOCKS化だけである • Dynamic link library の技術がSOCKS化を容易にしている • IPv6 での新しい機能 (IPSecなど)が簡単に利用できる • 二つの終端されたコネクションのリレーを行っているので

特徴 (2/2) • IPv4⇒IPv6 と IPv6⇒IPv4 両方の変換が可能である • 既存の client SOCKSv5 library がそのまま利用できる • IPv4 ⇒IPv6 の変換の場合は IPv4⇒ IPv4用に開発された既存の client SOCKSv5 library がそのまま利用できる • TCP と UDP両方のリレー変換が可能である • SOCKSv5 は TCP と UDP リレーをサポートしており、トランスレータでも同様に TCP と UDP のリレー変換にも対応している • 多段に連なった変換が可能である • アドレス情報をアプリケーション層で交換する FTP に対応可能 • トランスレータは容易にプロトコル変換ルーチンを導入することが可能 • fｔｐの例のように、どのようなプロトコルかがわかっている場合は、特別なプロトコル変換ルーチンを用いて対応可能 • 並列した複数のサーバにより、容易に負荷分散を行える

制限事項 • アドレス長の差に起因する本質的制限 • IPv6 と IPv4 は異なるプロトコルであるため、getpeername() や getsockname() 関数では本当のIP address情報を返せない。（空間の広さが等しく、SOCKSで変換するのでポート情報は正しい） • 実際のところ、これらの関数は多くの場合ポート情報の取得のために用いられるため、実質的制限は小さい • SOCKS 機構に依存する制限 • 現在の SOCKSv5 は異常なコネクションの張り方を行うアプリケーションには対応できず、トランスレータでもそれらには対応できない • Fake address を利用することによる制限 • Fake address はアプリケーションにおける一時的情報として扱う必要があり、ブックマークのようなものに記録してはならない。 • 多くのアプリケーションは IP address ではなくて FQDN を恒久的情報として、ブックマークに記録するので、実質的制限はほとんどない

100BASE-TX (Full-Duplex)Switching Hub Source SOCKS Client Translator1 SOCKS Server Translator2 SOCKS Server Destination 評価環境 OS FreeBSD2.2.7R IPv6 Implementation KAME etc. Source, Translator1, Translator2, Destination PCs (CPU PentiumII 400MHz Memory 128MB) Network 100BASE-TX (Full Duplex) Switching Hub

実装したSOCKS-based IPv6/IPv4 Translatorの評価 • 典型的な TCP と UDP のサービス(telnet, http, pop, ftp, tftp など) を用いたIPv4 IPｖ6間での相互通信を実現 • IPv4ノードからでもIPv6ノードでも相互通信コネクションが張れる • 特別な変換ルーチンを用いて、ftp もサポートIPアドレスを引数にとるftpコマンド (PORTとLPRT, PASVの LPSV返値) の適切な変換を実現 • IPv6のプロトコル実装に依存しないことを検証性能 • 一台の translatorサーバにつき同時に100 あまりの相互通信コネクションを実現各コネクションのスループットを合計して60 Mbpsを実現 • 標準的な規模のネットワークをサポートする十分な性能があることが実証された

IPv6への移行技術のまとめ • IPv6へ移行するための要求事項を明確化を行った • 多様な移行技術を比較し分類した • 鍵となる技術はいかにしてDNS名前解決機構を取り込むか • 最適な解として “Semi-Termination モデル” を選択 • “SOCKS-based IPv6/IPv4 Translator”としてそれを実装 • 実装を既に終え、評価及び検証も終えている • 典型的なサービスである (telnet, ftp, http, tftpなど)用いたIPv4 IPｖ6間での相互通信が性能などの問題もなく実現できることを検証 • （IETFに提案し、RFC3089として標準化を終えている） • その初期実装を http://www.socks.nec.com/において公開 • CGI登録を通した download 年間 5000件、世界80カ国からある

一日当たりの Download数

IPv6ならではの魅力的な新機能Connection/Link Status Investigation (CSI) を生む背景 • 現状の問題 • best-effortネットワークでは様々な理由（不適当なネットワーク設計、通信の輻輳など）により、通信品質の劣化が発生する • 要求事項として • 通信品質劣化に遭遇するのを避けたい • 通信経路のどこに問題やボトルネックがあるかを簡単に発見したい • その要求を満たすために • 通信経路に沿ったノードやネットワークの状態情報などのデータを効率的に収集する機構が欲しい • hop-by-hop でデータを獲得する機能を利用すれば、その機構を実現する最適な方法になる • IPv6にはhop-by-hop option があり、それを実現するための基礎となる機能があると共に歴史的にもよい時期にあたる

現状の状態調査機構（ツール）の問題点1/2 (ping) • ping • 良いツールである。単純であり end-to-end 通信の基本的状態情報を集めることができるしかし • 通信経路に沿ったhop-by-hopの状態情報を収集することはできない • 通信経路上のどこに問題やボトルネックがあるかを探し出すことはできない

現状の状態調査機構（ツール）の問題点2/2 (traceroute, pathchar) • tracestatus (pathchar) • 有効なツールではあるが、その機能は最適化されていない (この機構は他の目的のために用意された既存の機能を、その本来の目的とは違う方法で無理やり利用しているから) 2つの大きな制限(問題)と一つの小さな制限（問題） • 通信相手から自分への下りの経路を基本的に調査できない • ほとんどのユーザは下り（ダウンロード）経路の状態を調査を行いたいという要求があるため、これは致命的な問題になる • 調査のために数多くのプローブ／リプライパケットを発行する • 非効率的な方法 • この観点からすると、“pathchar” は “traceroute” より相当に多くのパケットを発行し、極めて非効率 • 複数のプローブを利用することは取得したデータの信頼性を下げてしまうかもしれない（二番目のプローブは前のプローブと同じ経路を通過しないかもしれない）

traceroute (or pathchar) 型の状態調査機構 MPMR (Multiple-Probe/Multiple-Reply) UDP packets Outgoing Path 3 node 1 node 2 1 4 2 5 6 source desti-nation ICMP messages node 5 node 4 Incoming Path

これらの問題点に対する解としてIPv6 hop-by-hop で状態調査を効率的に行う Connection/Link Status Investigation (CSI) を提案要求事項 • “上り”のパスのみならず “下り”のパスも調査できること • 調査のために発行するパケット数を最小化すること • 動的経路制御によって調査を行うパスが変化をしてしまう問題を避けること • 十分にシンプルな機構であること • 様々な規模や様々な型のネットワークに適応可能なこと • コネクションの到達性がない問題のあるネットワークでも動作して、問題を起こしている場所を発見できること

CSI 機構の設計 • 一般的なフレームワークとして • 実時間で上り及び下りの経路に沿ったノードの状態情報を、（最小数のパケットを用いた）効率的な方法で調査する機構 • 多様なデータに取得できるような拡張性を持たせる • 中間ノード（ルータ）での処理は簡単に • 複雑でインテリジェンスを必要とする処理はソースノードで • １つの新しいIPv6 Hop-by-Hop option • CSI option • ３つの新しい ICMPv6 メッセージ • Status Request / Status Reply • Status Report

Status Request / Reply (ICMPv6 messages) • Round trip loop を形成する一対のメッセージ • Status Requestメッセージ • （Source から Destinationへの) outgoing（上り)パスを担当 • Status Replyメッセージ • （Destination から Source への) incoming（下り)パスを担当 • ブーメランのような動作をする • 2つの役割がある • 経路に沿ったそれぞれのノードでのデータ取得の引き金になる • 取得したデータを自分自身のメッセージに添付し運ぶ • 取得したデータはメッセージ内のデータを記録するために事前に確保した空間に埋められて運ばれる • 空間を埋めるだけなので、メッセージの長さは変化させない • ほとんどの場合、一対のメッセージだけで経路に沿ったノードの状態情報を集めることが可能

Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Status Request / Reply (ICMPv6 messages) Status Request ICMPv6 message Outgoing Path node 1 node 2 source desti-nation node 5 node 4 Incoming Path Status Reply ICMPv6 message

Record format in Data Space(Record Route 動作の例) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| I. Class = 1| I. Type = 0| Reserved |R| Hop Limit Base| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Record Count | Report Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Number = 1|0 1| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | + Upper part of IPv6 Address [Incoming I/F] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | + Lower part of IPv6 Address [Incoming I/F] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Number = 2|0 1| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | + Upper part of IPv6 Address [Incoming I/F] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | + Lower part of IPv6 Address [Incoming I/F] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Number = 3|0 1| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | + Upper part of IPv6 Address [Incoming I/F] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | + Lower part of IPv6 Address [Incoming I/F] + | | +---------------------------------------------------------------+ Record 1 Record 2 Record 3

Status Report (ICMPv6 message) • スケーラビリティ問題を回避するためにStatus Report メッセージを導入する • データを運搬する容量 (メッセージ内に事前に確保した空間の広さ)は有限である • 事前に確保した空間が取得データで一杯になったとき全ての取得データはStatus Report メッセージを利用して状態調査を開始したイニシエータノードに運ばれる • Status Report メッセージが発行された後は Status Request/Replyプローブメッセージ内のデータを記録する空間を空にし、データ収集動作を続ける

Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Status Report (ICMPv6 message) Status Request ICMPv6 message Outgoing Path node 1 node 2 Status Report source desti-nation Status Report node 5 node 4 Incoming Path Status Reply ICMPv6 message

Operation モード • CSI機構はどんなネットワーク環境でも動作する必要がある • 通常のネットワークでは、効率的に動作するように • コネクションの到達性がないような問題のあるネットワークでは、問題点がどこにあるかを発見するために動作するように • この条件を満たすために“Operation モード” という考えを導入 • SPSR (Single-Probe/Single-Reply) モード • 通常のネットワークで通常の状態調査に用いる • SPMR (Single-Probe/Multiple-Reply) モード • 問題のあるネットワークで機能するために用いる • Status Report メッセージが通信経路に沿った全てのノードから発行される

Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option CSI in SPSR (Single-Probe/Single-Reply) mode Status Request ICMPv6 message Outgoing Path node 1 node 2 source desti-nation node 5 node 4 Incoming Path Status Reply ICMPv6 message

Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option Hop-by-Hop CSI Option CSI in SPMR (Single-Probe/Multiple-Reply) mode Status Request ICMPv6 message Outgoing Path node 1 node 2 source desti-nation Status Reports node 5 node 4 Incoming Path Status Reply ICMPv6 message

実装と評価 • CSI 機能をIPv6の新機能として実装し、評価及び検証を終えた • “tracestatus” CUIツールを作成 • 基本機能として動作する • “pathview” GUIツールを作成 • “tracestatus”のfront-endとして動作する • “tracestatus” と Status Request/Reply の関係は “ping” と Echo Request/Reply メッセージの関係と同じ • 典型的な使用法は、プローブパケットは周期的に発行し、ネットワーク状態を継続的に調査する • 初期プローブは経路に沿ったノードの(アドレスや所持するI/F数などの）静的情報を取得 • それに続く繰り返し発行されるプローブはノードの（カウンターなどの）動的情報を取得 • ソースルーティングを利用することにより、調査する通信経路を固定することが可能　初期プローブで経路を固定するためのアドレス情報を取得

“tracestatus”(CUI) と “pathview”(GUI)

node 1 node 1 node 2 node 2 source source desti-nation desti-nation node 5 node 5 node 4 node 4 タイムスタンプと実時間利用帯域計測 • 繰り返し発行する多重プローブを利用した計測 Repeated Times = n Repeated Times = n+1 At node X: Timestamp = Tn Octet Count = Cn At node X: Timestamp = Tn+1 Octet Count = Cn+1

途中通過ノード(ルータ）への実装の評価 • 途中通過ノード(ルータ）へのCSI機能の実装の影響が最も大きな関心事となる • 途中通過ノードにおける　CSI機能の性能（動作時間) のみ測定して評価した

nodeS 評価方法 • ソースルートしたパケットを評価のために用いた nodeS node A nodeB S->S=>S (n-1) times repeated S->A->B->…->A->B->S=>S For correction Main evaluation

中間ノードにおけるCSI 機能の動作時間

中間ノードにおける CSI 機能の動作の平均時間 • “Investigation Data Type”, “Operation Mode”, “Investigated Interface(s)　に依存する • “Number of passed nodes” には依存しない全ての値は < 200 μsec (十分小さい) 参考: 10Mbps, 300B のパケット ⇒ 通過するだけで(300 x 8 bit)/10M bps = 240 μsec

IPv6ならではの魅力的な新機能 CSI機構のまとめ • Hop-by-hopベースで実時間で状態調査を効率的に行う機構 Connection/Link Status Investigation (CSI) 機構を提案 • IPv6 の新機能として設計し実装し評価を行った • CSI機構では上りのパスのみならず下りのパスをも絶対最小の数（ほとんどの場合1対) のパケットを用いて効率的に状態調査を行う • 状態調査のための基本フレームワークとして設計した • 柔軟で拡張性に富む機構、多様な状態調査に用いることが可能 • Hop-by-hop ベースの実時間で正確な消費帯域測定を実現 • 経路上のボトルネックを見つけることが可能 • ネットワークの再設計を行うためのデータ取得に利用 • QoS を保証するネットワークでは、状態を検証する機構として利用 • シンプルでルータに対して複雑な動作を要求しない機構容易に実装できて中間ノード(ルータ）において性能問題を生じない

Protocols Design and Implementation for IPv6 Internet （ IPv6 インターネットに向けたプロトコルの設計と実装）