CSI

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はもう次世代のプロトコルではなく現世代のプロトコル
2
IPv6の未来とビジネス
(公聴会のコメントを受けて)
• IPv6の未来
– 普及は工学だけでなく、政治的要素が大きい
– IPv4と違いIPv6ではグローバルな着信が可能となること
が新しいサービスモデルを生む
– 移動体端末のIPｖ6化が普及の原動力になる
• IPv6のビジネスモデル
– SOCKS-based IPv6/IPv4 Translator は
• Client は Freeで配る
• 高性能なServer製品を作り、そこで利益を上げる
– アドレスが絶対的に足りない地域
日本、欧州、中国あたりが有力市場
3
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 の設計と実装
4
IPv4からIPv6へスムーズに移行する技術
3種類の移行技術
• Dual Stack
– IPv6とIPv4両方のプロトコルスタックを実装
– アドレス空間枯渇の問題を解決することができない
• Tunneling
– IPv4パケットへカプセル化してIPv6パケットを運ぶ
– IPv4の海を越えてIPv6の陸地間の通信
– IPv6ノードはIPv4ノードと通信をすることができない
• Translator
–
–
–
–
パケット及びプロトコルを変換する
異種プロトコル間の相互通信を実現する
移行初期から最終段階まで利用される技術
（本質的解で本発表で取り上げる移行技術）
5
Dual Stack
IPv4/IPv6 2重ネット
S
相手がIPv4ならIPv4
相手がIPv6ならIPv6
D
IPv6とIPv4両方のプロトコルスタックを実装
アドレス空間枯渇の問題を解決することができない
6
Tunneling
(パケットのカプセル化)
IPv4ネット
IPv6ネット
IPv6ネット
S
R
IPv6
IPv4へ
カプセル化
R
IPv6
D
トンネルの出入口
IPv4パケットへカプセル化してIPv6パケットを運ぶ
IPv4の海を越えてIPv6の陸地間の通信
IPv6ノードはIPv4ノードと通信をすることができない
7
Translator
(パケットの変換）
IPv4ネット
S
IPv6ネット
T
IPv4
IPv6
D
トランスレータ
パケット及びプロトコルを変換する
異種プロトコル間の相互通信を実現する
移行初期から最終段階まで利用される技術
（本質的解で本発表で取り上げる移行技術）
9
IPv6環境に移行するにあたっての
変換技術に必要とされる条件
• 現在IPv4で利用されている通信モデルでの
使いやすさを保持すること
• 既存の通信インフラとなる
フレームワーク（DNSなど）を保持すること
• 既存のIPv4用に作られたアプリケーションを
全く修正することなく
IPv4-IPv6間の相互通信に利用できること
• 多様なIPv4及びIPv6サービスをサポートできること
• スケーラブルで負荷分散に容易に対応できること
11
プロトコル変換の観点から
必要とされる機能の分析
• IP プロトコルの変換
– 各パケットの IP ヘッダの置き換え
– 置き換えに利用する IP アドレス空間の予約
– アドレスマッピングに伴う複雑なアドレス空間管理
• IP に関連するプロトコルの変換
– IP に関連するプロトコル (例えば ICMP) の変換
– アプリケーション層でアドレス情報を交換する
アプリケーション(例えば ftpなど) に対処する機能
12
ユーザアプリケーションの観点から
必要とされる機能の分析
ユーザアプリケーション内部での手続き
1. 通信相手を論理的ホスト名であるFQDNで指定
2. FQDN から IP アドレスへ“DNS名前解決 API” を利用して解決し
て、その情報をコネクションを確立のために用いる
FQDN が通信を開始する起点となる情報であり、
IPv4 及び IPv6に依存しない唯一の情報となっている
スムーズな変換機能に必要で、キーとなる重要な技術は
DNS 名前解決の機能を
どのようにトランスレータ機能に取り込むか
IPv4アドレスしか処理できない既存のアプリケーションで
いかにしてIPv6を示すAAAA レコードを解決するか
13
機能を実装するプロトコル層による分類
基本機能はどのプロトコル層に実装するかで決定される
• IP 層で実装 (NAT 技術の応用)
– IP ヘッダはIPv4とIPv6の間で透過的に(transparently)変換される
– 変換されるコネクションは終端されない
– “Transparent モデル”
• アプリケーション層での実装(ALG firewall/proxy 技術の応
用)
IPv4 と IPv6 の二つのコネクションは一旦終端されリレーされる
– ひとつは “Full-Termination モデル”
ユーザは内部の変換トポロジーなどの構造を知る必要があり、
手動で変換に必要な情報を設定する必要がある
– もう一方は “Semi-Termination モデル”
ユーザは内部の変換のための構造は基本的に知る必要がなく、
変換に必要な情報は、特別なプロトコル（例えば SOCKSなど）を
用いて内部で自動的に交換される
14
機能を実装するノード位置による分類
• Source ノードへの実装
– IPv4 アプリケーションはローカルに変換され、
IPv6アプリケーションがそこにあるように振舞う
– 長所: DNS 名前解決機能を変換機能の中に取り込める
– 短所: そのノードにあるローカルアプリケーションしか変換対象にできない
変換機能を全ての端末に実装する必要がある
• Intermediateノードへの実装 (一般的な利用法)
– IP 層への実装
通信パス上のルータに実装: 各ノードのdefault route をそのルータに設定
– アプリケーション層への実装
サーバとして動作: サーバの位置を各ノードに設定
– 長所: ネットワーク上にいる全てのノードが変換機能を利用可能
– 短所: DNS 名前解決を変換機能に取り込むことができない
• Destinationノードへの実装
– Source ノードに対して何ら制限を与えない
– Dual Stack の方法に似ているアドレス空間枯渇問題を解決できない
15
“Transparent モデル” の特徴
• IP ヘッダの変換に集中パケットが届けば、変換できる.
• Source ノードに対してなんら修正を必要としない
• 致命的問題: DNS 名前解決機能を変換機能の中にとりこめない
Source ノードは通信を開始することができない
• 解: DNS の問い合わせパケットを置き換えるというスケーラブル
ではない多くの制限を伴う機構を使う必要がある
• 基本的に正しく対応できなICMPv4 と ICMPv6の間の
複雑なプロトコル変換を行う必要がある
• 変換途中でパケット長が変わるので、性能劣化に直結する
パケットのフラグメンテーションを起こす危険性がある
• IPv6での新しい仕様(IPsec など)を利用することができない
“Transparent モデル” は問題点が多い
現在のネットワークフレームワークの柔軟性を欠く
18
“Full-Termination モデル” の特徴
• コネクションが一旦終端されてリレーされるため、
”Transparent モデル“ のほとんど問題は解決される
• 終端されるので、ICMPの変換は必要ない
• パケットサイズはリレーされるそれぞれのコネクションで調整
されるので、フラグメンテーションを起こす危険性はない
• IPｖ６独自の新しい機能を容易かつ効率的に取り込める
• 制限事項:ユーザは内部の変換トポロジーなどの構造を知り、
手動で変換に必要な情報を設定する必要がある
• もともと変換に必要な情報を転送できるような機能を持たない
アプリケーションの場合は、このモデルは利用できない。
21
“Semi-Termination モデル” の特徴
• “Full-Termination モデル”の持つ問題は解決されている
• 変換に必要な情報を自動的に内部で転送するために、
新しいプロトコルと機構を導入する
• Source ノードに新しい機能をインストールする必要がある
• 新しい機能のインストールにより、 DNS 名前解決の機能
をトランスレータ機能に取り込むことが可能
(このモデルの絶対的特徴でもある)
“Semi-Termination モデル” が最適と判断
SOCKS-based Translator として実現する
22
基本 Translator 機構
Client C
Translator T
Destination D
Translator
Application
Application
Same
APIs
Socks Lib
Socket, DNS
IPvX
Network I/F
Socksified
Connection
to D
to T
Socket, DNS
IPvX IPvY
Network I/F
data
to D (control)
to D
data
Socket, DNS
IPvY
Network I/F
Normal
Connection
23
DNS名前解決の手続き
(DNS Name Resolving Delegation and Address Mapping)
Application
socket
FQDN
1
gethostbyname2()
getaddreinfo()
4
DNS Server
7 real IP
6
3
connect()
2
FQDN
real IP
Translator
socket
FQDN fake IP
fake IP
socket
Socks Lib
FQDN
8
connect()
5
socksified connection
24
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に対してコネクションを張る
25
発展形 Translator 機構
(Multiple Chained Relay)
Client C
Translator T1
Translator T2
Destination D
Application
Same
APIs
Application
to D Translator2
T Translator1
Socks Lib to D
Socks Lib
T1 Socket, DNS to T2 Socket, DNS to D Socket, DNS
Socket, DNS to S
IPvY IPvZ
IPvZ
IPvX
IPvX IPvY
Network I/F
Network I/F
Network I/F
Network I/F
data
to D (control)
Socksified
Connection
data
to D (control)
Socksified
Connection
data
Normal
Connection
26
特徴 (1/2)
• DNS に全く手を加える必要がない
– Address map servers などというものは不要
– 変換のためのアドレス空間を予約する必要が全くない
• アプリケーションに依存しない
– 基本的にソケットとDNS名前解決APIを利用する
全てのアプリケーションに対して利用できる
– 例外: アプリケーション層でIPアドレス情報を交換するようなアプリ
ケーション (例えば ftp PORT など) は例外となる
• OS や NIC の種類に依存しない
– UNIX も Windows どちらのOSも対象にしている
– 物理的な NIC の種類に対する依存性はない
• 必要な処理は簡単な SOCKS化だけである
– Dynamic link library の技術が SOCKS化を容易にしている
• IPv6 での新しい機能 (IPSecなど)が簡単に利用できる
– 二つの終端されたコネクションのリレーを行っているので
28
特徴 (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ｔｐの例のように、どのようなプロトコルかがわかっている場合は、
特別なプロトコル変換ルーチンを用いて対応可能
• 並列した複数のサーバにより、容易に負荷分散を行える
29
制限事項
• アドレス長の差に起因する本質的制限
– IPv6 と IPv4 は異なるプロトコルであるため、getpeername() や
getsockname() 関数では本当のIP address情報を返せない。
（空間の広さが等しく、SOCKSで変換するのでポート情報は正しい）
– 実際のところ、これらの関数は多くの場合ポート情報の取得のために
用いられるため、実質的制限は小さい
• SOCKS 機構に依存する制限
– 現在の SOCKSv5 は異常なコネクションの張り方を行うアプリケーション
には対応できず、トランスレータでもそれらには対応できない
• Fake address を利用することによる制限
– Fake address はアプリケーションにおける一時的情報として扱う必要が
あり、ブックマークのようなものに記録してはならない。
– 多くのアプリケーションは IP address ではなくて FQDN を恒久的情報とし
て、ブックマークに記録するので、実質的制限はほとんどない
30
評価環境
100BASE-TX (Full-Duplex)
Switching Hub
Source
Translator1
SOCKS Client SOCKS Server
OS
IPv6 Implementation
Source, Translator1,
Translator2, Destination
Network
Translator2
SOCKS Server
Destination
FreeBSD2.2.7R
KAME etc.
PCs (CPU PentiumII 400MHz
Memory 128MB)
100BASE-TX (Full Duplex)
Switching Hub
31
実装した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 を実現
• 標準的な規模のネットワークをサポートする
十分な性能があることが実証された
32
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カ国からある
33
一日当たりの Download数
30
Tue
Mon
25
Thu
Mon
Tue
Tue Thu
04-13
v1.2
Mon
Tue
Thu
Tue FriWed
Mon
Fri Fri
Thu
WedWedFri
Thu
Mon
Mon Wed
ThuFri Wed
SunTue
Fri
Wed
Mon Wed
Wed
Tue
Wed
Fri
Tue
Tue
Wed
TueThu
Fri
Mon
Wed
Thu
Wed
MonMon
Fri Tue
Fri
Mon
Tue
Thu
Mon
Mon MonWed
Tue Tue
Thu
ThuSat
Mon
Sun
Thu
Tue Tue Mon Thu Tue
Thu
Tue
Tue
Wed
Fri
Wed Mon Fri
Tue
Fri TueWed Sat Tue Mon Sun FriThu Tue
Tue
Tue
Wed
Wed
Fri
Thu
Mon
Wed
Sat
Sat WedFri Sat
Wed
Wed
Mon
Wed
Thu
Fri
Thu Mon
Thu
MonThu Wed Sun
Tue
Fri Wed
Wed
Sat
Mon Sat
Thu
Wed Wed
Thu
Thu
TueTue Wed
Sun
WedThu
Fri Mon
Fri Fri
Mon
ThuThu
Fri Fri
MonThu
Sat Fri
Sun
SunMon
Tue
MonTue
Wed
Mon
Wed
Tue
Sun
Wed
Tue
Fri Sun
Tue
Wed
Sat Sat
Mon
TueTue Fri
Sun
Sat
Thu
Sat MonWed
Mon
Sat
Tue
Fri Fri SatFri Sun
Mon
Mon Fri Mon
Tue FriTueThu
SatSun
Sun
Sat Thu Fri
Sat
Sun
Fri
Sun
Wed
Thu
Sun SatSat
Mon
Tue
Fri
Sat
Sun
Wed Tue
MonMon
MonThu
Sun
WedWed
Fri
Sun
Thu
Fri
MonThuThu
FriWed
Mon
Wed Fri
Sun
Sun
Fri
Wed Sun
Sun
Sun
Fri
MonThu
Sun
Tue
Sat
Thu Tue
Mon
SatSat Fri Fri Tue
Thu
SatSat
TueMon
Sun Thu
Sun
Sat Fri Sat
WedFriThu
Sun
Mon
Tue
Sat Wed
Thu Thu
Fri Fri
Sat Sun
Wed
TueWed
Mon
Sun
MonWed
Thu
SunSun
Sat
Sun
Thu
Tue Sat
Mon
Sun
Wed
Sun Sun
SatSunSunSun Sat
SatSat
Fri
Sun
Mon
Mon
Tue
Sun
Sun
Thu
SatFri
02-04
ThuThu
Sat
Thu
Sun
Fri Wed
Mon Sat ThuSat Sun
Sun
Thu Sun
Wed
Sat
Thu
Tue
Sat
Sat
Sun
Sat
v1.1
SatSat
Fri
Sat Fri
Sat
Wed
Fri Sun
Sun
Sat
Sat Tue Sat Sun
Sun Sat
Tue
Thu
20
15
10
5
00-01-31
00-01-17
00-01-03
99-12-20
99-12-06
99-11-22
99-11-08
99-10-25
99-10-11
99-09-27
99-09-13
99-08-30
99-08-16
99-08-02
99-07-19
99-07-05
99-06-21
99-06-07
99-05-24
99-05-10
99-04-26
99-04-12
99-03-29
99-03-15
99-03-01
99-02-15
0
99-02-01
times
08-20
v1.3
34
IPv6ならではの魅力的な新機能
Connection/Link Status Investigation (CSI) を生む背景
• 現状の問題
– best-effort ネットワークでは様々な理由（不適当なネットワーク設計、
通信の輻輳など）により、通信品質の劣化が発生する
• 要求事項として
– 通信品質劣化に遭遇するのを避けたい
– 通信経路のどこに問題やボトルネックがあるかを簡単に発見したい
• その要求を満たすために
– 通信経路に沿ったノードやネットワークの状態情報などのデータを効
率的に収集する機構が欲しい
– hop-by-hop でデータを獲得する機能を利用すれば、その機構を実現
する最適な方法になる
– IPv6にはhop-by-hop option があり、それを実現するための基礎となる
機能があると共に歴史的にもよい時期にあたる
38
現状の状態調査機構（ツール）の問題点1/2
(ping)
• ping
– 良いツールである。単純であり end-to-end 通信の
基本的状態情報を集めることができる
しかし
– 通信経路に沿った hop-by-hop の状態情報を
収集することはできない
– 通信経路上のどこに問題やボトルネックがあるかを
探し出すことはできない
39
現状の状態調査機構（ツール）の問題点2/2
(traceroute, pathchar)
• tracestatus (pathchar)
– 有効なツールではあるが、その機能は最適化されていない
(この機構は他の目的のために用意された既存の機能を、
その本来の目的とは違う方法で無理やり利用しているから)
2つの大きな制限(問題)と一つの小さな制限（問題）
– 通信相手から自分への下りの経路を基本的に調査できない
• ほとんどのユーザは下り（ダウンロード）経路の状態を調査を行いたいという
要求があるため、これは致命的な問題になる
– 調査のために数多くのプローブ／リプライパケットを発行する
• 非効率的な方法
• この観点からすると、“pathchar” は “traceroute” より相当に多くのパケットを
発行し、極めて非効率
– 複数のプローブを利用することは取得したデータの信頼性を下げてしま
うかもしれない
（二番目のプローブは前のプローブと同じ経路を通過しないかもしれない）
40
traceroute (or pathchar) 型の状態調査機構
MPMR
(Multiple-Probe/Multiple-Reply)
UDP packets
Outgoing Path
3
1
node 1
2
node 2
4
5
6
source
destination
ICMP messages
Incoming Path
node 5
node 4
41
これらの問題点に対する解として
IPv6 hop-by-hop で状態調査を効率的に行う
Connection/Link Status Investigation (CSI) を提案
要求事項
• “上り”のパスのみならず “下り”のパスも調査できること
• 調査のために発行するパケット数を最小化すること
• 動的経路制御によって調査を行うパスが変化をしてしまう
問題を避けること
• 十分にシンプルな機構であること
• 様々な規模や様々な型のネットワークに適応可能なこと
• コネクションの到達性がない問題のあるネットワークでも動
作して、問題を起こしている場所を発見できること
42
CSI 機構の設計
• 一般的なフレームワークとして
– 実時間で上り及び下りの経路に沿ったノードの状態情報を、
（最小数のパケットを用いた）効率的な方法で調査する機構
– 多様なデータに取得できるような拡張性を持たせる
– 中間ノード（ルータ）での処理は簡単に
– 複雑でインテリジェンスを必要とする処理はソースノードで
• １つの新しい IPv6 Hop-by-Hop option
– CSI option
• ３つの新しい ICMPv6 メッセージ
– Status Request / Status Reply
– Status Report
43
CSI Option (IPv6 Hop-by-Hop option)
• CSI option が設定されたパケットは、
経路に沿ったノードを通過する際に、
そのノードの状態を調査し状態情報を取得する
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |
4n+2 alignment
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|Invest. Class| Invest. Type | Reserved
|R| Hop Limit Base|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identifier
| Record Count | Report Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
Data Space
+
|
|
|
|
44
Status Request / Reply (ICMPv6 messages)
• Round trip loop を形成する一対のメッセージ
– Status Request メッセージ
• （Source から Destinationへの) outgoing（上り) パスを担当
– Status Reply メッセージ
• （Destination から Source への) incoming （下り) パスを担当
• ブーメランのような動作をする
• 2つの役割がある
– 経路に沿ったそれぞれのノードでのデータ取得の引き金になる
– 取得したデータを自分自身のメッセージに添付し運ぶ
• 取得したデータはメッセージ内のデータを記録するため
に事前に確保した空間に埋められて運ばれる
– 空間を埋めるだけなので、メッセージの長さは変化させない
• ほとんどの場合、一対のメッセージだけで経路に沿った
ノードの状態情報を集めることが可能
45
Status Request / Reply (ICMPv6 messages)
Status Request ICMPv6 message
Outgoing Path
source
node 1
node 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
node 5
node 4
destination
Incoming Path
Status Reply ICMPv6 message
46
Record 2
Record 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 format in Data Space
(Record Route 動作の例)
47
Status Report (ICMPv6 message)
• スケーラビリティ問題を回避するために
Status Report メッセージを導入する
– データを運搬する容量 (メッセージ内に事前に確保した空間
の広さ)は有限である
• 事前に確保した空間が取得データで一杯になったとき
全ての取得データはStatus Report メッセージを利用して
状態調査を開始したイニシエータノードに運ばれる
• Status Report メッセージが発行された後は
Status Request/Reply プローブメッセージ内のデータを記録
する空間を空にし、データ収集動作を続ける
48
Status Report (ICMPv6 message)
Status Request ICMPv6 message
Outgoing Path
source
node 1
node 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
node 5
node 4
destination
Incoming Path
Status Reply ICMPv6 message
49
Operation モード
• CSI機構はどんなネットワーク環境でも動作する必要がある
– 通常のネットワークでは、効率的に動作するように
– コネクションの到達性がないような問題のあるネットワークでは、
問題点がどこにあるかを発見するために動作するように
• この条件を満たすために“Operation モード” という考えを導入
– SPSR (Single-Probe/Single-Reply) モード
• 通常のネットワークで通常の状態調査に用いる
– SPMR (Single-Probe/Multiple-Reply) モード
• 問題のあるネットワークで機能するために用いる
• Status Report メッセージが通信経路に沿った
全てのノードから発行される
50
CSI in SPSR (Single-Probe/Single-Reply) mode
Status Request ICMPv6 message
Outgoing Path
source
node 1
node 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
node 5
node 4
destination
Incoming Path
Status Reply ICMPv6 message
51
CSI in SPMR (Single-Probe/Multiple-Reply) mode
Status Request ICMPv6 message
Outgoing Path
source
node 1
node 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
node 5
node 4
destination
Incoming Path
Status Reply ICMPv6 message
52
実装と評価
• CSI 機能をIPv6の新機能として実装し、評価及び検証を終えた
• “tracestatus” CUIツールを作成
– 基本機能として動作する
• “pathview” GUIツールを作成
– “tracestatus”のfront-endとして動作する
• “tracestatus” と Status Request/Reply の関係は
“ping” と Echo Request/Reply メッセージの関係と同じ
• 典型的な使用法は、プローブパケットは周期的に発行し、
ネットワーク状態を継続的に調査する
– 初期プローブは経路に沿ったノードの
(アドレスや所持するI/F数などの）静的情報を取得
– それに続く繰り返し発行されるプローブはノードの
（カウンターなどの）動的情報を取得
• ソースルーティングを利用することにより、
調査する通信経路を固定することが可能
初期プローブで経路を固定するためのアドレス情報を取得
56
“tracestatus”(CUI) と “pathview”(GUI)
57
タイムスタンプと実時間利用帯域計測
• 繰り返し発行する多重プローブを利用した計測
Repeated Times = n
node 1
Repeated Times = n+1
node 2
node 1
destination
source
node 5
node 4
At node X: Timestamp = Tn
Octet Count = Cn
node 2
destination
source
node 5
node 4
At node X: Timestamp = Tn+1
Octet Count = Cn+1
C Cn  1  Cn
Consumed Bandwidth 

T Tn  1  Tn
58
途中通過ノード(ルータ）への実装の評価
• 途中通過ノード(ルータ）へのCSI機能の実装の影響が
最も大きな関心事となる
• 途中通過ノードにおける
CSI機能の性能（動作時間) のみ測定して評価した
OS
ノード（ルータ）
ネットワーク
Source code size
FreeBSD2.2.8R + KAME
PCs (Pentium II 400MHz)
100BASE-TX/10BASE-T Ethernet
1.2kline (on intermediate nodes)
59
評価方法
Investigation Data Type Name Address, Static, Compress, Dynamic, All
Operation Mode
SPSR, SPMR
Investigated Interface(s)
Incoming, Outgoing, Both
Number of passed nodes
from 20 to 32
• ソースルートしたパケットを評価のために用いた
node
S
node
A
node
S
node
B
(n-1) times repeated
S->S=>S
S->A->B->…->A->B->S=>S
Main evaluation
For correction
60
中間ノードにおけるCSI 機能の動作時間
200
180
160
:
140
Operation time (micro sec)
120
address
static
compress
dynamic
all
100
80
60
40
20
0
SR- SR- SR- MR- MR- MR- SR- SR- SR- MR- MR- MR- SR- SR- SR- MR- MR- MR- SR- SR- SR- MR- MR- MR- SR- SR- SR- MR- MR- MRI- O- B- I- O- B- I- O- B- I- O- B- I- O- B- I- O- B- I- O- B- I- O- B- I- O- B- I- O- B20 20 20 20 20 20 22 22 22 22 22 22 24 24 24 24 24 24 26 26 26 26 26 26 28 28 28 28 28 28
Operation Mode - Class (Investigated Interface) - # of passed nodes
61
中間ノードにおける
CSI 機能の動作の平均時間
• “Investigation Data Type”, “Operation Mode”,
“Investigated Interface(s) に依存する
• “Number of passed nodes” には依存しない
Record length (byte)
SPSR Incoming time (usec)
SPSR Outgoing time (usec)
SPSR Both
time (usec)
SPMR Incoming time (usec)
SPMR Outgoing time (usec)
SPMR Both
time (usec)
address
20
14.9
14.0
39.0
87.0
92.2
110.9
static
compress
28
20
24.0
14.3
24.4
14.4
62.4
39.9
93.0
87.0
99.4
93.5
124.8
112.0
dynamic
28
24.0
24.6
62.2
93.5
99.7
124.8
all
60
65.4
64.0
139.4
122.1
126.1
180.5
全ての値は < 200 μsec (十分小さい)
参考: 10Mbps, 300B のパケット ⇒
通過するだけで(300 x 8 bit)/10M bps = 240 μsec
62
IPv6ならではの魅力的な新機能 CSI機構のまとめ
• Hop-by-hop ベースで実時間で状態調査を効率的に行う機構
Connection/Link Status Investigation (CSI) 機構を提案
• IPv6 の新機能として設計し実装し評価を行った
• CSI機構では上りのパスのみならず下りのパスをも絶対最小の数
（ほとんどの場合1対) のパケットを用いて効率的に状態調査を行う
• 状態調査のための基本フレームワークとして設計した
• 柔軟で拡張性に富む機構、多様な状態調査に用いることが可能
•
•
•
•
•
Hop-by-hop ベースの実時間で正確な消費帯域測定を実現
経路上のボトルネックを見つけることが可能
ネットワークの再設計を行うためのデータ取得に利用
QoS を保証するネットワークでは、状態を検証する機構として利用
シンプルでルータに対して複雑な動作を要求しない機構
容易に実装できて中間ノード(ルータ）において性能問題を生じない
63
Plug and Play機能強化と拡張
Domain Name Auto-Registrationを生む背景
• IPv6は新たな通信分野 (移動体端末、自動車、家電、
ホームネットワークなど）の開拓を促進
• これらの装置の特徴
– その台数が非常に多い
– 手動で通信のための情報を設定するのが困難
– これらの装置のユーザは多くの場合
通信プロトコルに関する十分な知識を持っていない
• Plug and Play 機能なくしては、この分野へ展開できない
– 管理コストを低減する必要がある
• グローバルアドレスならでは特性を生かす
– End-to-End通信が一般的に
– 発信のみならず外部からの着信アクセスを可能に
• 実用的なPlug and Play 技術
– IPアドレスが自動設定できるだけで、実用的通信は実現できない
69
Plug and Play の視点から見た
IPアドレスとホスト名
• IPv6 アドレスはとても長くて覚えることが困難
• EUI64ベースのIPv6アドレスは規則性のない数字の連続と
なる複雑なアドレスであり、更に覚えることが困難
• 強い要求事項として:
– 通信相手を指定するのに、
IPv6 アドレスを用いて指定するのではなく、
容易に覚えることが可能な論理ホスト名で指定したい
– プラグインするIPv6ノードの論理ホスト名を
プラグイン動作に連係して自動的に登録したい
70
Domain Name Auto-Registration機構の目標
• 必要とされる機能は
– プラグインしたIPv6ノードをすばやく発見し、
– そのノードの論理ホスト名を設定し、
– 自動的にその正引き及び逆引きの情報をDNSへの登録を行う
• この機構は一連の autoconfiguration (plug and play) 機能の
鍵となる要素技術
• “Address Autoconfiguration” [RFC2462]でステートレスアドレス設定
された後に、引き続いて動作するPlug and Play機構として動作
• “Dynamic Updates in the DNS” [RFC2136] を
ドメイン名情報の登録に利用する
• “Dynamic Updates” をドメイン名情報を自動登録する機能に適応する
にあたっての問題点を明確にする
問題の解であり
Plug and Playでの通信やEnd-to-End通信を実現する上で
鍵となる技術として “Domain Name Auto-Registration” 機構を提案
71
プラグインする IPv6ノードに対する考慮
1. プラグインする IPv6 ノードは自分の好みを示せるような
十分が機能を持っていない
プラグインする IPv6 ノードにとっては、自分のドメイン名を
何にしたいかという好みを示すことは一般に困難
2. この機能の実現にあたり、プラグインする IPv6ノードに
新たな機能追加することを避けたい
3. プラグインするノードにとって本質的なことは
記憶可能な“何らか”のドメイン名を持つ(登録する)こと
実際にどのような名前が割り当てられるかは、
プラグインするノードの最大の関心事ではない
73
“デフォルトドメイン名”
“デフォルトドメイン名” という考えを導入
1. 新しくプラグインしたIPv6 ノードが出現する
2. その出現を自動的にすばやく検知する
3. そのノードに対応させる“デフォルトドメイン名” を選択す
る
4. その“デフォルトドメイン名” に対応する正引き及び逆引き
の情報をDNSサーバに自動的に登録する
もしノードがその“デフォルトドメイン名”に
不満足であれば、手動で改名可能
(plug and playでない環境において)
74
Dynamic Updates を利用する上での問題点1/2
Dynamic Updates [RFC2136] をドメイン名の自動登録を行う機構
に用いるには解決しなくてはならない問題がある
プラグインしたノードは:
1. DNSサーバからみて信用できるノードになれない
• プラグインしたノードからのDynamic Updatesメッセージは信用できない
一般にDNSサーバはそのメッセージを受け付けない
2. ノードのドメイン名情報をどのDNSサーバへ
登録に行けばよいかを知るのが困難
3. 登録すべき十分なドメイン名情報を用意するのが困難
• 登録するのに必要なFQDN情報を用意するために、
ノードが所属する DNS ゾーンの情報が必要だが、
プラグインしたばかりのノードがその情報を入手するのは一般に困難
75
Dynamic Updates を利用する上での問題点2/2
4. 同じ名前の二重登録を回避するための明確な方法がない
•
•
DNS サーバは受信したDynamic Updatesメッセージが
正しいフォーマットで、正しく認証されていれば、
その二重登録のチェックを行うことなく登録してしまう
(DNSサーバにとって、二重登録と上書き（更新）処理とを
区別することは本質的に実現できない)
5. プラグインノードから発生するDynamic Updates メッセージ数を
制御（制限)する機能が存在しない
•
悪意のある若しくは間違って設定されたノードからの
要求メッセージの影響を最小化したい
6. 登録メッセージを発行すべき時期が明確でない
•
いつ登録を行うかのタイミングの定義が必要
76
問題点に対する解としての機構の基本設計
“Domain Name Auto-Registration” 機構は
二つの新しい機能から成り立つ
• “Detector” 機能
– 新しいIPv6プラグインノードの出現を検出す
– 検出したアドレス“detected address” を“Registrar”に送る
• “Registrar” 機能
– 受信した“detected address”が
登録を必要とする情報であるか検証
– 検証されたら、そのノードの“デフォルトドメイン名” を用意
– “デフォルトドメイン名” 情報を DNS サーバに登録
Plugged-in IPv6 Node には全く機能を追加しない
既存のDAD（Duplicate Address Detection)仕様を利用
77
単一リンクの場合
DNS Servers
(4) Check & Name
R
Detector
(2) Detect
(1) Plug-in
Registrar
(3) Request
(5) Register
Plugged-in
IPv6 Node
78
単一リンクの場合
DNS Servers
Detector
RA prefix detected address
with Detector ID
R
DAD finished
start
Registrar
inverse query
domain
name
NS
address
address
Plugged-in
IPv6 Node
dynamic update
duplication check
finished
start
79
複数リンクの場合
DNS Servers
(4) Check & Name
Registrar
(3) Request
R1
(5) Register
Detector1
R2
Detector2
(2) Detect
(1) Plug-in
Plugged-in
IPv6 Node
Plugged-in
IPv6 Node
80
複数リンクの場合
DNS Servers
dynamic update
duplication check
finished
start
Registrar
inverse query
domain
name
R1
RA prefix
DAD start
finished
Detector1
detected address
with Detector ID
NS
address
address
Plugged-in
IPv6 Node
R2
Detector2
Plugged-in
IPv6 Node
81
典型的動作手順
Plugged-in
IPv6 Node
DAD (a)
link-local (b)
Router
Detector
NS
[no NA]
(c)
DAD (d)
global (e)
(f)
(g)
(h)
Registrar DNS servers
(RS)
detected address
with Detector ID
discarded
RA
NS
[no NA]
detected address
with Detector ID
check (i)
inverse
DNS query
(j)
(property (k)
query) (l)
(optional)
default domain name selected
(m)
Dynamic (n)
Updates (o)
(p)
regular info.
dynamic update
inverse info.
dynamic update
82
典型的動作手順
Plugged-in
IPv6 Node
DAD (a)
link-local (b)
(c)
DAD (d)
global (e)
(f)
(g)
(h)
Router
Detector
NS
[no NA]
(1) Plug-in
(RS)
RA
(2) Detect
NS
[no NA]
(4) Check & Name
(property (k)
query) (l)
(optional)
(m)
Dynamic (n)
Updates (o)
(p)
detected address
with Detector ID
discarded
(i)
(j)
check
Registrar DNS servers
(3) Request
detected address
with Detector ID
inverse
DNS query
default domain name selected
regular info.
dynamic update
(5) Register
inverse info.
dynamic update
83
実装と検証
• Detector–Registrar 間は http ベースのプロトコルを利用
• Plugged-in Nodeは BSD UNIXにもWindowsに対応
• 問題なく動作することを検証
Plugged-in IPv6 Node
OS
FreeBSD 4.4R, NetBSD 1.5.2, and
Windows 2000 with Technology Preview
Detector
OS
FreeBSD 4.4R, NetBSD 1.5.2
Registrar
OS
FreeBSD 4.4R, NetBSD 1.5.2
DNS Server
OS
FreeBSD 4.4R, NetBSD 1.5.2
DNS 実装
BIND 9.1.3
84
Plug and Play機能強化と拡張
Domain Name Auto-Registration機能のまとめ
• IPv6は新たな通信分野 (移動体端末、自動車、家電）の開拓を促進
• これらの装置は、台数が非常に多い、手動での設定が困難など独特
な特徴をもち、管理コストを軽減するPlug and Play 機能が必須
• グローバルアドレスならでは特性を生かし、
End-to-End通信を実現する上で通信相手を指定するのには、記憶が
困難なIPv6 アドレスではなく、記憶が容易な論理ホスト名が必要
• IPv6ノードに新たな機能を追加することなくして、プラグインしたノードを
すばやく検知し、論理ホスト名を選択し、DNSへの登録を自動的に行う
“Domain Name Auto-Registration” 機構を発案し実装し評価、
問題なく動作することを検証
• 今後は、足りないPlug and Play要素技術 (例えば、 Service Location
Protocol (SLP) によるサービスの自動発見など）の開発を通し
完全なPlug and Play の実現を目指す
• Plug and Playと相性が良くないセキュリティー機能の連係強化も課題
85
IPv6に向けて必要となる機能のまとめ
• IPv4からIPv6へスムーズに移行する技術
– 最小の制約でIPv6/IPv4相互通信を効率的に実現する
SOCKS-based IPv6/IPv4 Translatorの設計と実装
• IPv6ならではの魅力的な新機能
– IPv6 Hop-by-Hop Option機能を拡張し、
通信経路に沿って最小のコストでネットワークと通信装置の情報
を実時間で効率的に取得し問題点やボトルネックを発見できる
Connection/Link Status Investigation (CSI)の設計と実装
• Plug and Play機能強化と拡張
– プラグインしたIPv6ノードに自動的に論理ホスト名を設定し、
Plug and Playでの通信やEnd-to-Endの通信の鍵となる技術
Domain Name Auto-Registration の設計と実装
いずれの機能もIETFに提案して標準化の道を歩んでいる
SOCKS-based IPv6/IPv4 TranslatorはRFC3089として標準化を終えている
86

Download Report