protocols design and implementation for ipv6 internet （ ipv6 イ...

Protocols Design and Implementation for IPv6 Internet

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

大阪大学大学院基礎工学科情報数理系専攻ソフトウェア科学分野

北村　浩

2002/2/22 博士論文最終試験

2

IPv6 をめぐる背景• IPv4 のアドレス空間枯渇の問題に端を発し

次世代の IP （ IPng) の研究開発が 1994 年頃より本格化• IETF における議論の末、 IPv6 を IPng とすることに決定• IPv6 の最大の特徴は 2128 10≒ 38 に及ぶ広大でグローバルな空間• 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 はもう次世代のプロトコルではなく現世代のプロトコル

3

IPv6 の未来とビジネス( 公聴会のコメントを受けて )

• IPv6 の未来– 普及は工学だけでなく、政治的要素が大きい– IPv4 と違い IPv6 ではグローバルな着信が可能とな

ることが新しいサービスモデルを生む– 移動体端末の IP ｖ 6 化が普及の原動力になる

• IPv6 のビジネスモデル– SOCKS-based IPv6/IPv4 Translator は

• Client は Free で配る• 高性能な Server 製品を作り、そこで利益を上げ

る– アドレスが絶対的に足りない地域

日本、欧州、中国あたりが有力市場

4

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 の設計と実装

5

IPv4 から IPv6 へスムーズに移行する技術3 種類の移行技術

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

• Tunneling – IPv4 パケットへカプセル化して IPv6 パケットを運ぶ– IPv4 の海を越えて IPv6 の陸地間の通信– IPv6 ノードは IPv4 ノードと通信をすることができない

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

6

Dual Stack

DS

IPv4/IPv6 2 重ネット

相手が IPv4 なら IPv4相手が IPv6 なら IPv6

IPv6 と IPv4 両方のプロトコルスタックを実装アドレス空間枯渇の問題を解決することができない

7

Tunneling( パケットのカプセル化 )

DS

IPv6 ネット IPv6 ネットIPv4 ネット

R RIPv6 IPv6

IPv4 へカプセル化

トンネルの出入口

IPv4 パケットへカプセル化して IPv6 パケットを運ぶIPv4 の海を越えて IPv6 の陸地間の通信

IPv6 ノードは IPv4 ノードと通信をすることができない

9

Translator( パケットの変換）

DS

IPv6 ネットIPv4 ネット

TIPv4 IPv6

トランスレータ

パケット及びプロトコルを変換する異種プロトコル間の相互通信を実現する

移行初期から最終段階まで利用される技術（（本質的解本質的解で本発表で取り上げる移行技で本発表で取り上げる移行技

術）術）

11

IPv6 環境に移行するにあたっての変換技術に必要とされる条件

• 現在 IPv4 で利用されている通信モデルでの使いやすさを保持すること

• 既存の通信インフラとなるフレームワーク（ DNS など）を保持するこ

と• 既存の IPv4 用に作られたアプリケーションを

全く修正することなくIPv4-IPv6 間の相互通信に利用できること

• 多様な IPv4 及び IPv6 サービスをサポートできること

• スケーラブルで負荷分散に容易に対応できること

12

プロトコル変換の観点から必要とされる機能の分析

• IP プロトコルの変換– 各パケットの IP ヘッダの置き換え– 置き換えに利用する IP アドレス空間の予約– アドレスマッピングに伴う複雑なアドレス空間管

理• IP に関連するプロトコルの変換

– IP に関連するプロトコル ( 例えば ICMP) の変換– アプリケーション層でアドレス情報を交換する

アプリケーション ( 例えば ftp など ) に対処する機能

13

ユーザアプリケーションの観点から必要とされる機能の分析

ユーザアプリケーション内部での手続き1. 通信相手を論理的ホスト名である FQDN で指定2. FQDN から IP アドレスへ“ DNS 名前解決 API” を利用し

て解決して、その情報をコネクションを確立のために用いるFQDN が通信を開始する起点となる情報であり、 IPv4 及び IPv6 に依存しない唯一の情報となっている

スムーズな変換機能に必要で、キーとなる重要な技術はDNS 名前解決の機能を

どのようにトランスレータ機能に取り込むかIPv4 アドレスしか処理できない既存のアプリケーションで

いかにして IPv6 を示す AAAA レコードを解決するか

14

機能を実装するプロトコル層による分類

基本機能はどのプロトコル層に実装するかで決定される• IP 層で実装 (NAT 技術の応用 )

– IP ヘッダは IPv4 と IPv6 の間で透過的に (transparently) 変換される– 変換されるコネクションは終端されない– “Transparent モデル”

• アプリケーション層での実装 (ALG firewall/proxy 技術の応用 )IPv4 と IPv6 の二つのコネクションは一旦終端されリレーされ

る– ひとつは “ Full-Termination モデル”

ユーザは内部の変換トポロジーなどの構造を知る必要があり、手動で変換に必要な情報を設定する必要がある

– もう一方は “ Semi-Termination モデル”ユーザは内部の変換のための構造は基本的に知る必要がなく、変換に必要な情報は、特別なプロトコル（例えば SOCKS など）を用いて内部で自動的に交換される

15

機能を実装するノード位置による分類

• Source ノードへの実装– IPv4 アプリケーションはローカルに変換され、

IPv6 アプリケーションがそこにあるように振舞う– 長所 : DNS 名前解決機能を変換機能の中に取り込める – 短所 : そのノードにあるローカルアプリケーションしか変換対象にでき

ない変換機能を全ての端末に実装する必要がある

• Intermediate ノードへの実装 ( 一般的な利用法 ) – IP 層への実装

　通信パス上のルータに実装 : 各ノードの default route をそのルータに設定

– アプリケーション層への実装　サーバとして動作 : サーバの位置を各ノードに設定

– 長所 : ネットワーク上にいる全てのノードが変換機能を利用可能 – 短所 : DNS 名前解決を変換機能に取り込むことができない

• Destination ノードへの実装– Source ノードに対して何ら制限を与えない– Dual Stack の方法に似ている　アドレス空間枯渇問題を解決できない

18

“Transparent モデル”　の特徴• IP ヘッダの変換に集中パケットが届けば、変換できる .• Source ノードに対してなんら修正を必要としない• 致命的問題 : DNS 名前解決機能を変換機能の中にとりこめない

　 Source ノードは通信を開始することができない• 解 : DNS の問い合わせパケットを置き換えるというスケーラブ

ルではない多くの制限を伴う機構を使う必要がある• 基本的に正しく対応できな ICMPv4 と ICMPv6 の間の

複雑なプロトコル変換を行う必要がある• 変換途中でパケット長が変わるので、性能劣化に直結する

パケットのフラグメンテーションを起こす危険性がある• IPv6 での新しい仕様 (IPsec など ) を利用することができない

“Transparent モデル” は問題点が多い現在のネットワークフレームワークの柔軟性を欠く

21

“Full-Termination モデル” の特徴• コネクションが一旦終端されてリレーされるため、” Transparent モデル“ のほとんど問題は解決される

• 終端されるので、 ICMP の変換は必要ない• パケットサイズはリレーされるそれぞれのコネクションで調整されるので、フラグメンテーションを起こす危険性はない

• IP ｖ６独自の新しい機能を容易かつ効率的に取り込める • 制限事項 : ユーザは内部の変換トポロジーなどの構造を知り、

手動で変換に必要な情報を設定する必要がある• もともと変換に必要な情報を転送できるような機能を持たな

いアプリケーションの場合は、このモデルは利用できない。

22

“Semi-Termination モデル” の特徴

• “Full-Termination モデル”の持つ問題は解決されている• 変換に必要な情報を自動的に内部で転送するために、新しいプロトコルと機構を導入する

• Source ノードに新しい機能をインストールする必要がある

• 新しい機能のインストールにより、 DNS 名前解決の機能をトランスレータ機能に取り込むことが可能

( このモデルの絶対的特徴でもある )

“Semi-Termination モデル” が最適と判断SOCKS-based Translator として実現する

23

基本 Translator 機構

Application

Socket, DNSIPvX

Network I/F

Socket, DNSIPvY

Network I/F

Translator

Socket, DNSIPvY

Network I/FIPvX

Application

Client C Translator T Destination D

SameAPIs Socks Lib

to D

to T to D

SocksifiedConnection

NormalConnectiondata data

(control)to D

24

DNS 名前解決の手続き(DNS Name Resolving Delegation and Address Mapping)

ApplicationApplication

Socks LibSocks Lib

FQDN

FQDN

fake IPsocket

gethostbyname2()getaddreinfo()

connect()

socket

fake IP

FQDN

FQDNreal IP

DNS Server

TranslatorTranslator1

2

3

4

5

6

7 real IP

socksified connection

connect()

socket8

25

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 に対してコネクションを張る

26

発展形 Translator 機構(Multiple Chained Relay)

Socket, DNSIPvZ

Network I/F

Translator2

Socket, DNSIPvZ

Network I/FIPvY

Application

Translator T2 Destination D

to Dto T2 to D


NormalConnection

data data(control)to D

Application

Socket, DNSIPvX

Network I/F

Client C

SameAPIs

Socks Lib to Tto S


data(control)to D

Translator1

Socket, DNSIPvY

Network I/FIPvX

Translator T1

to Dto T1

Socks Lib

28

特徴 (1/2)• DNS に全く手を加える必要がない

– Address map servers などというものは不要– 変換のためのアドレス空間を予約する必要が全くない

• アプリケーションに依存しない– 基本的にソケットと DNS 名前解決 API を利用する

全てのアプリケーションに対して利用できる– 例外 : アプリケーション層で IP アドレス情報を交換するよう

なアプリケーション ( 例えば ftp PORT など ) は例外となる• OS や NIC の種類に依存しない

– UNIX も Windows どちらの OS も対象にしている– 物理的な NIC の種類に対する依存性はない

• 必要な処理は簡単な SOCKS 化だけである– Dynamic link library の技術が SOCKS 化を容易にしている

• IPv6 での新しい機能 (IPSec など ) が簡単に利用できる– 二つの終端されたコネクションのリレーを行っているので

29

特徴 (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ｔｐの例のように、どのようなプロトコルかがわかっている場合は、特別なプロトコル変換ルーチンを用いて対応可能

• 並列した複数のサーバにより、容易に負荷分散を行える

30

制限事項• アドレス長の差に起因する本質的制限

– IPv6 と IPv4 は異なるプロトコルであるため、 getpeername() や getsockname() 関数では本当の IP address 情報を返せない。（空間の広さが等しく、 SOCKS で変換するのでポート情報は正しい）

– 実際のところ、これらの関数は多くの場合ポート情報の取得のために用いられるため、実質的制限は小さい

• SOCKS 機構に依存する制限– 現在の SOCKSv5 は異常なコネクションの張り方を行うアプリケー

ションには対応できず、トランスレータでもそれらには対応できない• Fake address を利用することによる制限

– Fake address はアプリケーションにおける一時的情報として扱う必要があり、ブックマークのようなものに記録してはならない。

– 多くのアプリケーションは IP address ではなくて FQDN を恒久的情報として、ブックマークに記録するので、実質的制限はほとんどない

31

評価環境

100BASE-TX (Full-Duplex)

Switching Hub

SourceSOCKS Client

Translator1SOCKS Server

Translator2SOCKS Server

Destination

OS FreeBSD2.2.7R

IPv6 Implementation KAME etc.

Network100BASE-TX (Full Duplex)

Switching Hub

PCs (CPU PentiumII 400MHzMemory 128MB)

Source, Translator1,Translator2, Destination

32

実装した SOCKS-based IPv6/IPv4 Translator の評価

• 典型的な TCP と UDP のサービス (telnet, http, pop, ftp, tftp など ) を用いた IPv4 IP ｖ 6 間での相互通信を実現

• IPv4ノードからでも IPv6ノードでも相互通信コネクションが張れる

• 特別な変換ルーチンを用いて、 ftp もサポートIP アドレスを引数にとる ftp コマンド (PORT と LPRT, PAS

V の LPSV 返値 ) の適切な変換を実現• IPv6 のプロトコル実装に依存しないことを検証

性能• 一台の translator サーバにつき

同時に 100 あまりの相互通信コネクションを実現各コネクションのスループットを合計して 60 Mbps を実現

• 標準的な規模のネットワークをサポートする十分な性能があることが実証された

33

IPv6 への移行技術のまとめ• IPv6 へ移行するための要求事項を明確化を行った• 多様な移行技術を比較し分類した• 鍵となる技術はいかにして DNS 名前解決機構を取り込むか• 最適な解として “ Semi-Termination モデル” を選択• “SOCKS-based IPv6/IPv4 Translator” としてそれを実装• 実装を既に終え、評価及び検証も終えている• 典型的なサービスである (telnet, ftp, http, tftp など ) 用いた IPv4 I

P ｖ 6 間での相互通信が性能などの問題もなく実現できることを検証

• （ IETF に提案し、 RFC3089 として標準化を終えている）• その初期実装を http://www.socks.nec.com/ において公開• CGI登録を通した download 年間 5000件、世界 80カ国からあ

る

34

Thu

Fri

SatSun

Mon

Tue

Wed

Thu

Fri

SatSun

Mon

Tue

WedThu

Fri

Sat

Sun

Mon

Tue

WedThu

Fri

SatSunMonTueWed

Thu

FriSatSunMon

Tue

Wed

Thu

Fri

Sat

SunMonTue

Wed

Thu

FriSat

Sun

MonTue

Wed

Thu

Fri

Sat

Sun

MonTue

WedThu

Fri

Sat

SunMonTue

Wed

Thu

Fri

Sat

Sun

Mon

TueWed

Thu

Fri

Sat

Sun

MonTue

Wed

Thu

Fri

SatSun

Mon

Tue

Wed

Thu

Fri

Sat

SunMon

Tue

Wed

Thu

Fri

Sat

SunMon

TueWed

ThuFri

SatSun

MonTue

Wed

Thu

FriSat

Sun

Mon

TueWed

Thu

FriSatSun

Mon

Tue

Wed

Thu

Fri

Sat

SunMon

Tue

Wed

ThuFri

SatSun

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

Wed

Thu

Fri

Sat

SunMonTueWed

ThuFriSat

Sun

Mon

Tue

Wed

Thu

Fri

SatSun

MonTue

Wed

Thu

Fri

Sat

Sun

Mon

TueWed

Thu

Fri

SatSun

MonTue

Wed

Thu

Fri

Sat

Sun

Mon

TueWed

ThuFriSat

SunMon

TueWed

Thu

Fri

Sat

SunMon

Tue

WedThu

FriSatSun

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

Wed

ThuFri

Sat

Sun

Mon

Tue

WedThu

Fri

Sat

Sun

Mon

Tue

Wed

Thu

Fri

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

Wed

ThuFri

Sat

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

Wed

Thu

FriSat

Sun

MonTue

WedThuFri

Sat

Sun

Mon

Tue

Wed

Thu

FriSat

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Sun

MonTue

Wed

Thu

FriSat

Sun

MonTue

Wed

Thu

FriSat

Sun

MonTue

Wed

Thu

Fri

Sat

Sun

Mon

Tue

WedThu

Fri

SatSun

MonTueWed

Thu

Fri

Sat

Sun

MonTue

Wed

Thu

Fri

Sat

Sun

MonTue

Wed

Thu

Fri

SatSun

Mon

TueWed

ThuFriSatSun

Mon

Tue

Wed

Thu

FriSat

Sun

MonTue

Wed

Thu

Fri

Sat

Sun

0

5

10

15

20

25

30

99-0

2-01

99-0

2-15

99-0

3-01

99-0

3-15

99-0

3-29

99-0

4-12

99-0

4-26

99-0

5-10

99-0

5-24

99-0

6-07

99-0

6-21

99-0

7-05

99-0

7-19

99-0

8-02

99-0

8-16

99-0

8-30

99-0

9-13

99-0

9-27

99-1

0-11

99-1

0-25

99-1

1-08

99-1

1-22

99-1

2-06

99-1

2-20

00-0

1-03

00-0

1-17

00-0

1-31

times

02- 04v1.1

04- 13v1.2

08- 20v1.3

一日当たりの Download 数

38

IPv6 ならではの魅力的な新機能 Connection/Link Status Investigation (CSI) を生む背景

• 現状の問題– best-effort ネットワークでは様々な理由（不適当なネットワーク

設計、通信の輻輳など）により、通信品質の劣化が発生する• 要求事項として

– 通信品質劣化に遭遇するのを避けたい– 通信経路のどこに問題やボトルネックがあるかを簡単に発見した

い• その要求を満たすために

– 通信経路に沿ったノードやネットワークの状態情報などのデータを効率的に収集する機構が欲しい

– hop-by-hop でデータを獲得する機能を利用すれば、その機構を実現する最適な方法になる

– IPv6 には hop-by-hop option があり、それを実現するための基礎となる機能があると共に歴史的にもよい時期にあたる

39

現状の状態調査機構（ツール）の問題点 1/2 (ping)

• ping

– 良いツールである。単純であり end-to-end 通信の基本的状態情報を集めることができる

しかし– 通信経路に沿った hop-by-hop の状態情報を収集することはできない

– 通信経路上のどこに問題やボトルネックがあるかを探し出すことはできない

40

現状の状態調査機構（ツール）の問題点 2/2 (traceroute, pathchar)

• tracestatus (pathchar) – 有効なツールではあるが、その機能は最適化されていない

( この機構は他の目的のために用意された既存の機能を、その本来の目的とは違う方法で無理やり利用しているから )

2 つの大きな制限 ( 問題 ) と一つの小さな制限（問題）– 通信相手から自分への下りの経路を基本的に調査できない

• ほとんどのユーザは下り（ダウンロード）経路の状態を調査を行いたいという要求があるため、これは致命的な問題になる

– 調査のために数多くのプローブ／リプライパケットを発行する• 非効率的な方法• この観点からすると、“ pathchar” は “ traceroute” より相当に多くのパケッ

トを発行し、極めて非効率– 複数のプローブを利用することは取得したデータの信頼性を下げてし

まうかもしれない（二番目のプローブは前のプローブと同じ経路を通過しないかもしれない）

41

traceroute (or pathchar) 型の状態調査機構

source

node 1 node 2

desti-nation

node 5 node 4

Outgoing Path

Incoming Path

1

2

3

4 5

6

UDP packets

ICMP messages

MPMR (Multiple-Probe/Multiple-Reply)

42

これらの問題点に対する解として IPv6 hop-by-hop で状態調査を効率的に行う

Connection/Link Status Investigation (CSI) を提案

要求事項• “ 上り”のパスのみならず “下り”のパスも調査でき

ること • 調査のために発行するパケット数を最小化すること• 動的経路制御によって調査を行うパスが変化をしてしま

う問題を避けること• 十分にシンプルな機構であること• 様々な規模や様々な型のネットワークに適応可能なこと• コネクションの到達性がない問題のあるネットワークで

も動作して、問題を起こしている場所を発見できること

43

CSI 機構の設計

• 一般的なフレームワークとして– 実時間で上り及び下りの経路に沿ったノードの状態情報を、

（最小数のパケットを用いた）効率的な方法で調査する機構– 多様なデータに取得できるような拡張性を持たせる– 中間ノード（ルータ）での処理は簡単に– 複雑でインテリジェンスを必要とする処理はソースノードで

• １つの新しい IPv6 Hop-by-Hop option – CSI option

• ３つの新しい ICMPv6 メッセージ– Status Request / Status Reply– Status Report

44

CSI Option (IPv6 Hop-by-Hop option)• CSI option が設定されたパケットは、

経路に沿ったノードを通過する際に、そのノードの状態を調査し状態情報を取得する

4n+2 alignment+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|M|Invest. Class| Invest. Type | Reserved |R| Hop Limit Base|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identifier | Record Count | Report Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ Data Space +| || |

45

Status Request / Reply (ICMPv6 messages)

• Round trip loop を形成する一対のメッセージ– Status Request メッセージ

• （ Source から Destination への ) outgoing （上り ) パスを担当– Status Reply メッセージ

• （ Destination から Source への ) incoming （下り ) パスを担当• ブーメランのような動作をする• 2 つの役割がある

– 経路に沿ったそれぞれのノードでのデータ取得の引き金になる

– 取得したデータを自分自身のメッセージに添付し運ぶ• 取得したデータはメッセージ内のデータを記録する

ために事前に確保した空間に埋められて運ばれる– 空間を埋めるだけなので、メッセージの長さは変化させない

• ほとんどの場合、一対のメッセージだけで経路に沿ったノードの状態情報を集めることが可能

46

source

node 1 node 2

desti-nation

node 5 node 4

Outgoing Path

Incoming Path

Status Request ICMPv6 message

Status Reply ICMPv6 message

Status Request / Reply (ICMPv6 messages)

Hop-by-HopCSI Option






47

Record format in Data Space (Record Route 動作の例 )

Rec

ord

1R

ecor

d 2

Rec

ord

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] +| |+---------------------------------------------------------------+

48

Status Report (ICMPv6 message)

• スケーラビリティ問題を回避するために Status Report メッセージを導入する

– データを運搬する容量 ( メッセージ内に事前に確保した空間の広さ ) は有限である

• 事前に確保した空間が取得データで一杯になったとき全ての取得データは Status Report メッセージを利

用して状態調査を開始したイニシエータノードに運ばれる

• Status Report メッセージが発行された後は Status Request/Reply プローブメッセージ内のデータ

を記録する空間を空にし、データ収集動作を続ける

49

source

node 1 node 2

desti-nation

node 5 node 4

Outgoing Path

Incoming Path



Status Report (ICMPv6 message)







Status Report

Status Report

50

Operation モード

• CSI 機構はどんなネットワーク環境でも動作する必要がある– 通常のネットワークでは、効率的に動作するように– コネクションの到達性がないような問題のあるネットワークでは、

問題点がどこにあるかを発見するために動作するように

• この条件を満たすために“ Operation モード” という考えを導入– SPSR (Single-Probe/Single-Reply) モード

• 通常のネットワークで通常の状態調査に用いる– SPMR (Single-Probe/Multiple-Reply) モード

• 問題のあるネットワークで機能するために用いる• Status Report メッセージが通信経路に沿った全てのノードから発行される

51

source

node 1 node 2

desti-nation

node 5 node 4

Outgoing Path

Incoming Path



CSI in SPSR (Single-Probe/Single-Reply) mode







52

source

node 1 node 2

desti-nation

node 5 node 4

Outgoing Path

Incoming Path



CSI in SPMR (Single-Probe/Multiple-Reply) mode







Status Reports

56

実装と評価• CSI 機能を IPv6 の新機能として実装し、評価及び検証を終え

た• “tracestatus” CUIツールを作成

– 基本機能として動作する • “pathview” GUIツールを作成

– “tracestatus” の front-end として動作する• “tracestatus” と Status Request/Reply の関係は

“ ping” と Echo Request/Reply メッセージの関係と同じ• 典型的な使用法は、プローブパケットは周期的に発行し、

ネットワーク状態を継続的に調査する– 初期プローブは経路に沿ったノードの

( アドレスや所持する I/F 数などの）静的情報を取得

– それに続く繰り返し発行されるプローブはノードの（カウンターなどの）動的情報を取得

• ソースルーティングを利用することにより、調査する通信経路を固定することが可能

　初期プローブで経路を固定するためのアドレス情報を取得

57

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

58

タイムスタンプと実時間利用帯域計測

• 繰り返し発行する多重プローブを利用した計測

source

node 1 node 2

desti-nation

node 5 node 4

Repeated Times = n

At node X: Timestamp = Tn

Octet Count = Cn

source

node 1 node 2

desti-nation

node 5 node 4

Repeated Times = n+1

At node X: Timestamp = Tn+1

Octet Count = Cn+1

nn

nn

TT

CC

T

C

1

1Bandwidth Consumed

59

途中通過ノード ( ルータ）への実装の評価

• 途中通過ノード ( ルータ）への CSI 機能の実装の影響が最も大きな関心事となる

• 途中通過ノードにおける　CSI 機能の性能（動作時間 ) のみ測定して評価した

OS FreeBSD2.2.8R + KAME

ノード（ルータ）

PCs (Pentium II 400MHz)

ネットワーク 100BASE-TX/10BASE-T Ethernet

Source code size 1.2kline (on intermediate nodes)

60

S->A->B->…->A->B->S=>S

評価方法

• ソースルートしたパケットを評価のために用いた

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

nodeS

node A

nodeB

(n-1) times repeated

nodeS

S->S=>S

Main evaluationFor correction

61

0

20

40

60

80

100

120

140

160

180

200

SR-I-20

SR-O-20

SR-B-20

MR-I-20

MR-O-20

MR-B-20

SR-I-22

SR-O-22

SR-B-22

MR-I-22

MR-O-22

MR-B-22

SR-I-24

SR-O-24

SR-B-24

MR-I-24

MR-O-24

MR-B-24

SR-I-26

SR-O-26

SR-B-26

MR-I-26

MR-O-26

MR-B-26

SR-I-28

SR-O-28

SR-B-28

MR-I-28

MR-O-28

MR-B-28

Operation Mode - Class (Investigated Interface) - # of passed nodes

Op

erat

ion

tim

e (m

icro

sec

)

:

address

static

compress

dynamic

all

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

62

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

• “Investigation Data Type”, “Operation Mode”, “Investigated Interface(s) 　に依存する

• “Number of passed nodes” には依存しないaddress static compress dynamic all

20 28 20 28 60SPSR Incoming time (usec) 14.9 24.0 14.3 24.0 65.4SPSR Outgoing time (usec) 14.0 24.4 14.4 24.6 64.0SPSR Both time (usec) 39.0 62.4 39.9 62.2 139.4SPMR Incoming time (usec) 87.0 93.0 87.0 93.5 122.1SPMR Outgoing time (usec) 92.2 99.4 93.5 99.7 126.1SPMR Both time (usec) 110.9 124.8 112.0 124.8 180.5

Record length (byte)

参考 : 10Mbps, 300B のパケット ⇒ 通過するだけで (300 x 8 bit)/10M bps = 240 μsec

全ての値は < 200 μsec (十分小さい )

63

IPv6 ならではの魅力的な新機能 CSI 機構のまとめ

• Hop-by-hop ベースで実時間で状態調査を効率的に行う機構 Connection/Link Status Investigation (CSI) 機構を提案

• IPv6 の新機能として設計し実装し評価を行った• CSI 機構では上りのパスのみならず下りのパスをも絶対最小の数

（ほとんどの場合 1 対 ) のパケットを用いて効率的に状態調査を行う• 状態調査のための基本フレームワークとして設計した• 柔軟で拡張性に富む機構、多様な状態調査に用いることが可能

• Hop-by-hop ベースの実時間で正確な消費帯域測定を実現• 経路上のボトルネックを見つけることが可能• ネットワークの再設計を行うためのデータ取得に利用• QoS を保証するネットワークでは、状態を検証する機構として利用• シンプルでルータに対して複雑な動作を要求しない機構

容易に実装できて中間ノード ( ルータ）において性能問題を生じない

69

Plug and Play 機能強化と拡張Domain Name Auto-Registration を生む背

景• IPv6 は新たな通信分野 ( 移動体端末、自動車、家電、

ホームネットワークなど）の開拓を促進• これらの装置の特徴

– その台数が非常に多い– 手動で通信のための情報を設定するのが困難– これらの装置のユーザは多くの場合

通信プロトコルに関する十分な知識を持っていない

• Plug and Play 機能なくしては、この分野へ展開できない– 管理コストを低減する必要がある

• グローバルアドレスならでは特性を生かす– End-to-End 通信が一般的に– 発信のみならず外部からの着信アクセスを可能に

• 実用的な Plug and Play 技術– IP アドレスが自動設定できるだけで、実用的通信は実現できな

い

70

Plug and Play の視点から見たIP アドレスとホスト名

• IPv6 アドレスはとても長くて覚えることが困難• EUI64ベースの IPv6 アドレスは規則性のない数字の連

続となる複雑なアドレスであり、更に覚えることが困難

• 強い要求事項として :

– 通信相手を指定するのに、IPv6 アドレスを用いて指定するのではなく、容易に覚えることが可能な論理ホスト名で指定したい

– プラグインする IPv6 ノードの論理ホスト名をプラグイン動作に連係して自動的に登録したい

71

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” 機構を提案

73

プラグインする IPv6 ノードに対する考慮

1. プラグインする IPv6 ノードは自分の好みを示せるような十分が機能を持っていない

プラグインする IPv6 ノードにとっては、自分のドメイン名を

何にしたいかという好みを示すことは一般に困難2. この機能の実現にあたり、プラグインする IPv6 ノードに

新たな機能追加することを避けたい

3. プラグインするノードにとって本質的なことは記憶可能な“何らか”のドメイン名を持つ (登録

する ) こと

実際にどのような名前が割り当てられるかは、プラグインするノードの最大の関心事ではない

74

“ デフォルトドメイン名”

“ デフォルトドメイン名” という考えを導入

1. 新しくプラグインした IPv6 ノードが出現する2. その出現を自動的にすばやく検知する3. そのノードに対応させる“デフォルトドメイン名” を選択する

4. その“デフォルトドメイン名” に対応する正引き及び逆引きの情報を DNS サーバに自動的に登録する

もしノードがその“デフォルトドメイン名”に不満足であれば、手動で改名可能(plug and play でない環境において )

75

Dynamic Updates を利用する上での問題点 1/2

Dynamic Updates [RFC2136] をドメイン名の自動登録を行う機構に用いるには解決しなくてはならない問題がある

プラグインしたノードはプラグインしたノードは :1. DNS サーバからみて信用できるノードになれない

• プラグインしたノードからの Dynamic Updates メッセージは信用できない一般に DNS サーバはそのメッセージを受け付けない

2. ノードのドメイン名情報をどの DNS サーバへ登録に行けばよいかを知るのが困難

3. 登録すべき十分なドメイン名情報を用意するのが困難• 登録するのに必要な FQDN 情報を用意するために、

ノードが所属する DNS ゾーンの情報が必要だが、プラグインしたばかりのノードがその情報を入手するのは一般に困難

76

Dynamic Updates を利用する上での問題点2/2

4. 同じ名前の二重登録を回避するための明確な方法がない• DNS サーバは受信した Dynamic Updates メッセージが正しいフォーマットで、正しく認証されていれば、その二重登録のチェックを行うことなく登録してしまう

• (DNS サーバにとって、二重登録と上書き（更新）処理とを区別することは本質的に実現できない )

5. プラグインノードから発生する Dynamic Updates メッセージ数を制御（制限 ) する機能が存在しない

• 悪意のある若しくは間違って設定されたノードからの要求メッセージの影響を最小化したい

6. 登録メッセージを発行すべき時期が明確でない• いつ登録を行うかのタイミングの定義が必要

77

問題点に対する解としての機構の基本設計

“Domain Name Auto-Registration” 機構は二つの新しい機能から成り立つ

• “Detector” 機能 – 新しい IPv6 プラグインノードの出現を検出す– 検出したアドレス“ detected address” を“ Registrar” に送

る• “Registrar” 機能

– 受信した“ detected address” が登録を必要とする情報であるか検証

– 検証されたら、そのノードの“デフォルトドメイン名” を用意

– “ デフォルトドメイン名” 情報を DNS サーバに登録 Plugged-in IPv6 Node には全く機能を追加しない

既存の DAD （ Duplicate Address Detection)仕様を利用

78

DNS Servers

R RegistrarDetector

Plugged-inIPv6 Node

(1) Plug-in

(2) Detect (3) Request

(4) Check & Name

(5) Register

単一リンクの場合

79

DNS Servers

R RegistrarDetector

Plugged-inIPv6 Node

単一リンクの場合

NS addressDAD finished

RA prefix detected addresswith Detector ID

inverse querydomain name

duplication checkfinished

DAD start duplication checkstart

address dynamic update

80

DNS Servers

R1

Registrar

Detector1

Plugged-inIPv6 Node

R2

Plugged-inIPv6 Node

Detector2

(1) Plug-in(2) Detect

(3) Request

(4) Check & Name

(5) Register

複数リンクの場合

81

DNS Servers

R1

Registrar

Detector1

Plugged-inIPv6 Node

複数リンクの場合

NS addressDAD finished

RA prefix detected addresswith Detector ID

inverse querydomain name

duplication checkfinished

DAD start

duplication checkstart

R2

Plugged-inIPv6 Node

Detector2

address

dynamic update

82

典型的動作手順Plugged-inIPv6 Node Router Detector Registrar DNS servers

(a)(b)(c)

(d)(e)(f)(g)(h)

(i)(j)

(k)(l)

(m)(n)(o)(p)

discarded

DADlink-local

DADglobal

[no NA] detected addresswith Detector ID

NS

NS[no NA]

(RS)RA

detected addresswith Detector ID

check

regular info.dynamic update

inverse info.dynamic update

DynamicUpdates

default domain name selected

(propertyquery)

inverseDNS query

(optional)

83

Plugged-inIPv6 Node Router Detector Registrar DNS servers

(a)(b)(c)

(d)(e)(f)(g)(h)

(i)(j)

(k)(l)

(m)(n)(o)(p)

discarded

DADlink-local

DADglobal

[no NA] detected addresswith Detector ID

NS

NS[no NA]

(RS)RA

detected address

with Detector IDcheck

regular info.dynamic update

inverse info.dynamic update

DynamicUpdates

default domain name selected

(propertyquery)

inverseDNS query

(optional)

(1) Plug-in

(2) Detect(3) Request

(4) Check & Name

(5) Register

典型的動作手順

84

実装と検証• 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


DNS Server


DNS 実装 BIND 9.1.3

85

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 と相性が良くないセキュリティー機能の連係強化も課題

86

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 として標準化を終えている

protocols design and implementation for ipv6 internet （ ipv6 イ...

Documents