IP アドレスの管理方法の提案と評価 NTMobile における仮想

NTMobile

^における

仮想

アドレスの管理方法の提案と評価

加古 将規

鈴木 秀和

内藤 克浩

渡邊 晃

概要：我々は，IPv4/IPv6混在環境において通信接続性と移動透過性を同時に実現する技術としてNTMobile

（Network Traversal with Mobility）を提案している．NTMobileでは，NTMobileの機能を実装した端末

（NTM端末）に対して，実IPアドレスとして利用されないアドレス空間の中から一意な仮想IPアドレス を割り当てる必要がある．そのため，IPv4においては，十分な仮想IPv4アドレス数が確保できないとい う課題があった．また，IPv6においては，詳細な仮想IPアドレスの管理方法が未検討であった．そこで，

本論文では仮想IPv4アドレスと仮想IPv6アドレスそれぞれにおいての管理手法について提案する．

Proposal of Management Method of Virtual IP Addresses in NTMobile and its Evaluation

Kako Masanori^1,a) Suzuki Hidekazu² Naito Katsuhiro³ Watanabe Akira^2,b)

1.

はじめに

現在のIPネットワークではIPv4アドレスの枯渇が問 題となっており，短期的な解決策としてNATを導入し，

NAT配下のネットワークにプライベートネットワークを 構築することが一般的となっている．また，IPv4アドレ ス枯渇問題の長期的な解決策としてIPv6アドレスが検討 されているが，IPv6アドレスはIPv4アドレスと互換性が ないプロトコルとして定義されているため，即座にIPv6 ネットワークに移行することができない．そのためしばら くの間，IPネットワークはIPv4ネットワークとIPv6ネッ トワークが混在した環境が続くことが想定される．そのた め，アドレス空間としてIPv4プライベート，IPv4グロー バル，IPv6の3種類が混在し，通信接続性が確保できない 場合があるという課題が存在する．即ち，IPv4において

1 名城大学大学院理工学研究科

Graduate School of Science and Technology, Meijo Univer- sity

2 名城大学理工学部

Faculty of Science and Technology, Meijo University

3 愛知工業大学情報科学部

Faculty of Information Science, Aichi Institute of Technology

a) [email protected]

b) [email protected]

はグローバルアドレス空間側からプライベートアドレス空 間に対して通信を開始することができない（NAT越え問 題）．また，IPv4とIPv6の互換性がないため，直接通信 を行うことができない．

 一方，公共無線網の普及や携帯端末の発達により，移動 しながら通信を行いたいという要求が増加している．しか し，ネットワークの切り替えに伴いIPアドレスが変化す ると，通信を継続することができない．そのため通信中に IPアドレスが変化しても通信を継続できる技術（移動透過 性技術）が必要である．

 上記の課題を解決する既存技術としてDSMIP（Dual Stack Mobile IPv6）[7]が存在する．DSMIPは，IPv6ネッ トワークにおける移動透過性技術MIPv6（Mobile IPv6） [8]と，IPv4ネットワークにおける移動透過性技術MIPv4

（Mobile IPv4）[9]を結合した技術である．MIPv6は経路 最適化などが導入され，IPv6環境を前提とすれば実用にで きる規格と言えるが，IPv6環境でないと利用できないとい う課題が存在する．一方，MIPv4は，NAT環境を想定す る必要があり，以下のような課題が存在する．Mobile IP Traversal of NAT Devices[10]は，MIPv4をNAT環境で も利用できるように拡張したものである．しかし，この規 格では，NAT配下の端末への通信接続性を確保するため

にHA（Home Agent）をグローバル空間に設置する必要が ある．即ち，移動端末にはHoA（Home Address）として グローバルIPアドレスを割り振る必要があり，グローバ ルIPアドレスの枯渇に相反するという課題がある．移動 端末に対してプライベートIPアドレスを割り当てながら 移動透過性を実現する技術[11], [12]も存在するが，NAT に特殊な機能を追加するため，既存のネットワークに導入 することは難しい．

 そこで我々はIPv4/IPv6混在環境において通信接続性 と移動透過性を同時に実現する技術として，NTMobile

（Network Traversal with Mobility）[1], [2], [3], [4], [5], [6]

を提案している. NTMobileでは，NTMobileの機能を実 装した端末（NTM端末）に対して，端末の位置に依存しな い仮想IPアドレスを割り当てる．端末のアプリケーショ ンは仮想IPアドレスを通信相手のIPアドレスと認識し通 信を行う．仮想IPアドレスに基づくパケットは実IPアド レスでカプセル化し，通信相手に送信する．仮想IPアド レスは実ネットワークのアドレス体系の違いやネットワー ク切り替えによるアドレス変換に影響されないため，アプ リケーションはネットワークの制約を一切受けないという 利点がある．NTMobileの仮想IPアドレスは，実IPアド レスと重複することを防ぐために実ネットワークで利用さ れないアドレス帯域から生成し，端末に割り当てる．しか し，IPv4においては，仮想IPアドレス帯域として利用可 能なアドレス帯域が小さいため，NTMobileを大規模シス テムに適用できない．そのため，このままではNTMobile の拡張性がないという課題があった．また，IPv6において は，具体的な仮想IPアドレスの管理方法が未検討の状態 である．

 そこで，本論文では，自端末の仮想IPv4アドレスと通信 相手の仮想IPv4アドレスを端末内部で自律的に生成する 方式を提案する．端末内部で生成された仮想IPv4アドレ スはNTMobileの通信を一意に識別する通信識別子Path IDと関連付ける．通信中は，Path IDをキーとして通信 相手の仮想IPv4アドレスの検索を行い，パケット内の仮 想IPv4アドレスを端末が管理する仮想IPv4アドレスへと 変換する．また，仮想IPv6アドレスにおいては明確な管 理方法を定義する．仮想IPv6アドレスにDC（Direction Coordinator）のグローバルIPv4アドレスを付加すること で，DC単位で仮想IPv6アドレスを管理する．以上の手 法により，IPv4における仮想IPアドレスに係わる制約を 除去することができる．IPv6においては，仮想IPv6アド レスがDC間で重複しないことを保証できるため，アドレ ス管理を容易にすることができる．

 以下，2章でNTMobileの概要と仮想IPアドレスの管 理にについて説明する．そして，3章で提案方式の動作，4 章で提案方式の実装，5章で提案方式の評価について述べ，

6章でまとめる．

2. NTMobile

2.1 NTMobileの概要

図1にNTMobileの概要を示す．NTMobileは，NTM 端末，通信経路を指示するDC（Direction Coordinator），

エンドエンドでの通信が行えない場合にパケットの中継を 行うRS（Relay Server）によって構成される．DCおよび RSは，デュアルスタックネットワークに設置し，ネット ワークの規模に応じて複数台設置することができる．

 NTMobileは，NTM端末に対して位置に依存しない仮 想IPアドレスを割り当て，アプリケーションは仮想IPア ドレスに基づいた通信を行う．仮想IPアドレスは端末の 移動により変化しないため，通信中に端末がネットワーク を切り替えた場合でも，アプリケーションやCNに対して IPアドレスの変化を隠蔽し，移動透過性を実現する．仮 想IPアドレスに基づくパケットは，実IPアドレスでカプ セル化を行い，通信相手に送信される．NTM端末間の通 信はDCの指示により常に最適な通信経路で通信を行うこ とができる．端末どうしが直接通信を行えない場合（例え ば，両端末がIPv4 onlyネットワークとIPv6 onlyネット ワークに接続されている場合），RS経由で通信を行う事が できる．その場合であっても複数のRSの中から適切な1 台を選択し，冗長経路の少ない経路を生成できる．

2.2 仮想IPアドレスの管理に係わる課題

現状のNTMobileでは，IPv4の仮想アドレスとして，

IANA（Internet Assigned Numbers Authority）で規定さ れた「198.18.0.0/15」[13]のアドレス帯域を利用している．

このアドレス帯域はネットワーク性能試験用に確保され た帯域であるため，実IPアドレスとして利用されること がない．この帯域を，DC同士が連携して管理し，全ての NTM端末の仮想アドレスが重複しないように割り当てて いる．しかし，このアドレス空間はわずか13万個しかな く，NTMobileの普及を考えると少ない．この制約を除去 することがNTMobileの最大の課題となっている．また，

IPv6の仮想アドレスについては，これまでに具体的な規 定がなかった．IPv6ではアドレスが潤沢に存在するため，

上記のような制約はないものの，重複しないような管理が 必要である．

3.

提案方式

本論文では，IPv4における仮想アドレスに係わる制約を 一切除去する．また，IPv6における規約を明確に定義す る．さらに，DC間の連携を不要とし，アドレス管理を容 易にする．

3.1 提案方式の概要

IPv4とIPv6のアドレスの制約条件が異なるため，異な

UDP Tunnel Relationship between Virtual IP and NTM Node UDP communication/

TCP session NAT

Relay Server

Direction Coordinator

NTM Node NTM Node

General Node

IPv6 Network IPv4 Private Network

IPv4 Global Network Dual Stack Network

Handover Communication based on Virtual IP address

Real Network Dual Stack Virtual Network

図1 NTMobileの概要

る方法を用いて仮想IPアドレスを決定する．仮想IPv4ア ドレスにおいては，NTM端末が仮想IPv4アドレスを自律 的に生成し，Path IDと呼ぶ通信識別子を用いてNTMobile の通信を一意に識別する．パケットの受信側で仮想IPア ドレスを変換することにより通信を実現する．また，仮想 IPv6アドレスにおいては，DCが自身のグローバルIPv4 アドレスと個々のDC内で重複しない乱数を付加すること により，一意な仮想IPv6アドレスを生成する．IPv6はア ドレスが十分に存在するため，アドレス変換は不要である．

3.2 通信開始端末の仮想IPアドレスの生成

図2に端末起動時に仮想IPアドレスを生成する動作を 示す．通信開始端末MNは端末起動時にMNを管理する DC_MNに対して，NTM Registration Requestを送信し，

NTM端末の実IPv4/v6アドレス（RIP4MN，RIP6MN）の 登録を行う．DCMNは，この時点で，NTM端末の仮想IPv6 アドレスをDC_MN内で重複しないように生成し，NTM端 末の端末情報とともにデータベースに登録する．DCMN

は登録後，MNにNTM Registration Responseを送信し，

MNの仮想IPv6アドレスを通知する．

 図3に仮想IPv6アドレスのフォーマットを示す．仮想 IPv6アドレスは，IPv6アドレスの上位64bitをネットワー ク部とし，下位64bitをホスト部として定義する．ネッ トワーク部の上位32bitは仮想IPアドレス領域のネット ワークプレフィックスと定義し，実ネットワークで利用さ れない「2001:db8::/32」[14]を用いる．このアドレス帯域 はAPNIC（Asia Pacific Network Information Centre）に よって文書作成用に予約された帯域であり，実IPアドレ スとして利用されないことが保証されている．ネットワー ク部の下位32bitには，仮想IPv6アドレスを管理するDC のグローバルIPv4アドレスを記述する．これにより，DC が異なれば仮想IPv6アドレスが重複しないことが保証さ

MN

RIP4：RIP4_MN RIP6：RIP6_MN FQDN：FQDN

MN

NTM Registration Request

DC_MN

NTM Registration Response

Notice of VirtualIPv6Address Notice of Node information

VIP6MN

RIP4MN

Generation of VirtualIPv6Address

Generation of Virtual IPv4Address RIP6MN

図2 端末起動時の動作

NTM Node’s Unique ID DC ’s IPv4 Address

Virtual IPv6 Domain

Network（64bit） Host（64bit）

32bit 32bit

図3 仮想IPv6アドレスのフォーマット

れる．ホスト部の64bitには，DC内で重複しないように 生成した乱数を用いる．

 次に，MNはNTM Registration Responseを受信した際 に，静的に自らの仮想IPv4アドレスを生成する．この仮想 IPv4アドレスは固定値でよく，これまでに利用してきた仮 想IPアドレス帯域「198.18.0.0/15」の中から，198.18.0.1 とする．その後，MNは自端末のIPアドレスとして，仮 想IPv4アドレス（198.18.0.1）と仮想IPv6アドレス（図 3の形式）をアプリケーションに認識させる．

3.3 通信相手端末の仮想IPアドレスの生成・通知 図4に，通信開始時において通信相手の仮想IPアドレ スをどのように生成・取得を行うかを示す．

MNとCNがIPv4アプリケーションを利用している場 合，MNとCNがそれぞれ相手の仮想IPアドレスを自律的 に生成する．即ち，通信相手がどのような仮想IPv4アド レスを使用しているかには関与しない．MNはDCMNに対 してNTM Direction Requestを送信し，通信相手端末CN の名前解決およびトンネル構築の指示を依頼する．DCMN

はDNSの仕組みを利用して，NSレコードからDC_CNを 探索し，NTM Information Request / ResponseにてCN の端末情報を取得する．CNの端末情報を取得したDCMN

はNTM Route Directionに通信識別子Path ID_MN−CN， 通信相手の仮想IPv6アドレスを含む通信経路の指示を載 せてMNおよびCNに送信する．このとき，仮想IPv4ア ドレスの情報は含まない．DC_MNからNTM Route Direc- tionを受信したMNは，端末内部で一意となるCNの仮 想IPv4アドレスとしてVIP4Aを生成する．VIP4Aを生 成したMNは，VIP4_AをPath ID_MN−CNと関連付けて，

トンネル通信の情報を記録するトンネルテーブルに登録す る．MNはDNS応答メッセージ内の通信相手のIPv4アド レスをVIP4A に変更し，アプリケーションに渡す．同様 に，DCMNのNTM Route DirectionをDCCNから受信し たCNは，端末内部で一意となるMNの仮想IPv4アドレ スとしてVIP4Bを生成し，自端末のトンネルテーブルに Path ID_MN−CNとともに登録する．

 MNとCNがIPv6アプリケーションを利用している場 合，IPv4で示したような変換は行わず，VIP6CNを記載 したDNS応答メッセージをそのままアプリケーションに 渡す．

3.4 トンネル通信時の動作

図5に，NTM端末間において提案方式によるトンネル 通信時のアドレス遷移を示す．図中において，矢印は「送 信元アドレス→宛先アドレス」であることを示す．

• IPv4アプリケーションの場合

MNのIPv4アプリケーションは，自身の仮想IPv4ア ドレスをVIP4MN，CNの仮想IPv4アドレスをVIP4A

として認識している．また，CNのIPv4アプリケー ションは，自身の仮想IPv4アドレスをVIP4CN，MN の仮想IPv4アドレスをVIP4_Bとして認識している．

MNのIPv4アプリケーションがCNへパケットを送 信する際，送信元アドレスにVIP4MN，宛先アドレス にVIP4_A が記載された仮想IPパケットが生成され る．この仮想IPパケットは実IPアドレスでカプセ ル化された後，CNへ送信される．このとき，カプセ ル化されたパケットにはNTMobileの情報を記載し たNTMヘッダが付加されている．NTMヘッダには

User Space Kernel Space

NTMobile Kernel Module

Real I/F Virtual I/F

Packet Manipulation (Encapsulation /Decapsulation )

Tunnel Table Netfilter

NTMobile Deamon

Tunnel Establishment Applications

Netlink Socket

図6 NTM端末のモジュール構成

Path IDが含まれる．CNはカプセル化パケットを受 信すると，パケットのデカプセル化を行い仮想IPパ ケットを抽出する．その後，Path IDを元に自身のト ンネルテーブルを検索し，MNの仮想IPv4アドレス VIP4Bを取得する．CNはパケット内の送信元アドレ スをVIP4MNからVIP4Bへ，宛先アドレスをVIP4A

からVIP4_CNへ変換し，CNのIPv4アプリケーショ ンへ渡す．

また，CNのIPv4アプリケーションがMNへパケッ トを送信する際は，MNが同様にデカプセル化時にパ ケット内の仮想IPv4アドレスを変換を行う．

• IPv6アプリケーションの場合

IPv6においては，仮想IPv6アドレスがDCにより一 意に配布されるため，IPv4のような通信中のアドレス 変換は行わない．そのため，IPv6では，図5のような 仮想IPパケットのカプセル化・デカプセル化のみで 通信を行う．

4.

実装

NTMobileの基本動作はLinuxにおいて既に動作が検証 されている．そこでNTM端末のNTMobileモジュールに 提案方式に係わる改造を加えた．

 図6にNTM端末のモジュール構成を示す．NTM端末 はユーザ空間のNTMobileデーモンと，カーネル空間の NTMobileカーネルモジュールにより動作する．NTMobile デーモンはDCへのNTM端末情報の登録と仮想IPアド レスの取得，およびDCの指示に従ったトンネル構築を行 う．カーネルモジュールはパケットのカプセル化/デカプ セル化および暗号化処理を行う．

 提案方式による仮想IPv4アドレスの管理は，NTMobile デーモン内のトンネル構築を行うモジュールを改造する．

また，トンネル通信中の処理は，NTMobileカーネルモ ジュール内のデカプセル化を行うモジュールを改造する．

DC_MN DC_CN

MN CN

Generation of Virtual IPv4 Address (VIP4_A) and

Registration to Tunnel Table

NTM Direction Request

NTM Information Request/Response

NTM Route Direction NTM Route Direction

NTM Tunnel Reqest/Response

UDP Tunnel

RIP4：RIP4

CN

VIP4：VIP4_CN RIP6：RIP6_CN VIP6：VIP6_CN FQDN：FQDN_CN

Notice of Path ID and VIP6

Path ID_MN-CN Path ID_MN-CN

RIP4：RIP4

MN

VIP4：VIP4_MN RIP6：RIP6_MN VIP6：VIP6_MN FQDN：FQDN_MN

FQDN_CN

RIP4_CN VIP6_CN Name Resolution

RIP4_CN

VIP6_CN RIP4_MN VIP6_MN

MN’s Tunnel Table Path ID MN’s VIP 4 Path ID_MN-CN VIP4_MN

CN’s VIP4 VIP4_A

Generation of Virtual IPv4 Address (VIP4_B) and

Registration to Tunnel Table CN’s Tunnel Table Path ID MN’s VIP4 Path ID_MN-CN VIP4_B

CN’s VIP4 VIP4_CN RIP6_CN

RIP6_MN RIP6_CN

図4 通信開始時の動作

MN

Application NTMobile RIP4：RIP4_MN VIP4：VIP4_MN RIP6：RIP6_MN VIP6：VIP6_MN

UDP Tunnel VIP4_MN← VIP4_A

RIP4_MN→ RIP4_CN UDP Tunnel

After Encapsulation VIP4_MN→ VIP4_A

VIP4_MN→ VIP4_A

RIP4_MN← RIP4_CN VIP4_B← VIP4_CN

VIP4_B→ VIP4_CN VIP4_MN→ VIP4_A

CN’s Tunnel Table Path ID MN’s VIP Path ID_MN-CN VIP4_B

CN’s VIP VIP4_CN

After Encapsulation

VIP4_B← VIP4_CN VIP4_MN← VIP4_A

CN’s Tunnel Table Path ID MN’s VIP Path ID_MN-CN VIP4_MN

CN’s VIP VIP4_A

CN

Application NTMobile RIP4：RIP4_CN VIP4：VIP4_CN RIP6：RIP6_CN VIP6：VIP6_CN

VIP4_B← VIP4_CN VIP4_B→ VIP4_CN

RIP6_MN→ RIP6_CN UDP Tunnel

VIP6_MN→ VIP6_CN

VIP6_MN→ VIP6_CN

VIP6_MN→ VIP6_CN

RIP6_MN← RIP6_CN UDP Tunnel

VIP6_MN← VIP6_CN

VIP6_MN← VIP6_CN

VIP6_MN← VIP6_CN Application

for IPv4

Application for IPv6

図5 トンネル通信時のアドレス遷移

5.

評価

試作モジュールにて仮想IPv4アドレスにおけるトンネ ル通信の検証と性能測定を行った．

 図7に試験ネットワークの構成を，表1に各装置の仕様 を示す．NTM端末MNおよびCNはLinuxをインストー ルした実機PCに実装し，プライベートネットワークへと 直接接続した．試験ネットワークでは，NATなどが含ま

MN DC

1000 BASE-T Private Network

CN

図7 ネットワーク構成

表1 NTM端末の仕様

  MN CN

Hardware Thirdwave Prime Thirdwave Prime

OS Ubuntu 10.04 Ubuntu 10.04

Linux Kernel 2.6.32-21-generic 2.6.32-21-generic CPU Intel Core i7-860 Intel Core i7-930

Memory 3GB 3GB 

表2 トンネル通信時のスループット測定結果

      Conventional Proposal

Throughput(Mbps) 402.5 400.4 

れていないが提案方式の検証を行ううえでは，図7の構成 で十分と判断した．MN，CN，DCを1000BASE-Tによる 有線LANで接続した．今回はアドレス生成処理が未実装 であるため，通信相手の仮想IPv4アドレスを静的に設定 した．

 MNとCN間でiperf^*1を用いたTCP通信を行い，動 作検証およびスループットの測定を行った．ここでは，従 来のNTMobileによるトンネル通信と提案方式によるトン ネル通信のスループットを比較した．スループット測定に は，10秒間のスループット測定をMN，CN間で10回行 い，その平均値を算出した．

 表2にNTM端末間のトンネル通信によるスループット の測定結果を示す．従来方式に比べて提案方式のスルー プットは0.5%低い値となった．この結果より，提案方式 の通信において，NTM端末の仮想IPv4アドレス変換処理 がスループットの低下に大きな影響を及ぼすことがないこ とがわかった．

6.

まとめ

本論文では，NTMobileの仮想IPv4アドレスおよび仮 想IPv6アドレスの管理方法について提案を行った．仮想 IPv4アドレスにおいては，NTM端末内部で仮想IPv4ア ドレスを自律的に生成する．Path IDで通信を識別し，通 信パケットの仮想IPアドレスをNTM端末内部で自ら生 成した仮想IPアドレスに変換する方式を提案した．これ により，限られたアドレス帯域でNTMobileをほぼ無限の

*1 http://sourceforge.net/projects/iperf/

規模まで運用できるようになった．また，仮想IPv6アド レスにおいては，IPアドレスのフォーマットおよび一意 なIPアドレスの生成手法について提案した．仮想IPv6ア ドレスにDCのグローバルIPv4アドレスを付加すること で，DC単位で仮想IPv6アドレスを管理する．これによ り，DC間で仮想IPv6アドレスが重複しないことを保証 できるため，アドレス管理が容易になった．

 Linux上で仮想IPv4アドレスにおける提案方式の実装 を行い，動作を検証した．従来のNTMobileと提案方式に よるNTMobileを用いてNTM端末間のトンネル通信によ るスループットを比較し，提案方式によるスループットの 劣化がほとんどないことを確認した．

参考文献

[1] 内藤克浩，上醉尾一真，西尾拓也，水谷智大，鈴木秀和，

渡邊 晃，森香津夫，小林英雄：NTMobileにおける移動 透過性の実現と実装，情報処理学会論文誌，Vol.54, No.1, pp. 380―393(2013).

[2] 鈴木秀和，上醉尾一真，水谷智大，西尾拓也，内藤克浩，渡

邊 晃：NTMobileにおける通信接続性の確立手法と実装，

情報処理学会論文誌，Vol.54, No.1, pp. 367―379(2013).

[3] 上醉尾一真，鈴木秀和，内藤克浩，渡邊 晃：IPv4/IPv6 混在環境で移動透過性を実現するNTMobileの実装と 評価，情報処理学会論文誌，Vol.54, No.10, pp. 2288― 2299(2013).

[4] 納堂博史，鈴木秀和，内藤克浩，渡邊 晃：NTMobileに おける自立的経路最適化の提案，情報処理学会論文誌，

Vol.54, No.1, pp. 394―403(2013).

[5] 土井敏樹，鈴木秀和，内藤克浩，渡邊 晃：NTMobileに おけるアドレス変換型リレーサーバの実装と動作検証，情 報処理学会研究報告. MBL, [モバイルコンピューティン グとユビキタス通信研究会研究報告]，Vol.2013-MBL-67, No.11, pp. 1-6(2013)．

[6] 上醉尾一真，鈴木秀和，内藤克浩，渡邊 晃：IPv6ネット ワークにおけるNTMobileの検討，情報処理学会研究報告.

MBL, [モバイルコンピューティングとユビキタス通信研

究会研究報告]，Vol.2011-MBL-59, No.9, pp. 1-7(2011)． [7] H. Soliman.：Mobile IPv6 Support for Dual Stack Hosts

and Routers, RFC5555, IETF(2009).

[8] D. Johnson, C. Perkins, J. Arkko.：Mobility Support in IPv6, RFC3775, IETF(2004).

[9] C. Perkins.： IP Mobility Support for IPv4, Revised, RFC5944, IETF(2010).

[10] H. Levkowetz and S. Vaarala.：Mobile IP Traversal of Network Address Translation (NAT) Devices, RFC3519, IETF(2003).

[11] 井戸上彰，久保健，横田英俊，長谷川亨，大橋正良：独立 に管理されたMobile IPネットワーク間のローミング手 順とその実装，情報処理学会研究報告. MBL, [モバイル コンピューティングとユビキタス通信研究会研究報告]， Vol.2002-MBL-022, No.94, pp. 31-38(2002)．

[12] 井戸上彰，久保健，横田英俊：プライベートアドレス を使用するモバイルネットワーク間のローミング手順 とその実装，情報処理学会論文誌， Vol.44, No.12, pp.

2958–2967(2003)．

[13] S. Bradner.: Benchmarking Methodology for Network Interconnect Devices, RFC2544, IETF(1999).

[14] G. Huston, A. Lord, P. Smith.: IPv6 Address Prefix Re- served for Documentation, RFC3849, IETF(2004).

NTMobile における 仮想 IP アドレスの管理方法の提案と評価

加古将規

鈴木秀和

内藤克浩

渡邊晃

†

名城大学大学院 理工学部研究科

††

名城大学 理工学部

‡ †

愛知工業大学 情報科学部

研究背景



インターネット通信の需要増加

►公衆無線網やスマートフォンなどの携帯端末の普及

►IPv4/IPv6の混在環境

IPv4

と

アドレスは互換性が無い

►NAT越え技術の要求

IPv4

アドレスの枯渇に伴い，

を導入し，プライベートネットワークを

►

移動透過性技術の要求



現在の

ネットワークでは，

アドレスによって通信を識別



移動時などのネットワーク切り替えによって，端末のIPアドレスが変化 移動しながらの通信ができない

NAT

の外側から内側の端末にアクセスできない

NAT:Network Address Translation 1

IPv4/IPv6

間では直接通信ができない

 NAT

越えと移動透過性を同時に実現する技術

►NTM端末 (NTMobile Node)

NTMobile

を実装した端末



仮想IPアドレスによる通信

►DC (Direction Coordinator)



通信経路の指示



仮想IPアドレスの管理・配布

►

仮想

アドレス



端末の位置に依存しないIPアドレス

►DCはグローバルネットワーク上に分散配置可能



負荷分散が可能

NTMobile(Network Traversal with Mobility)

2 MN（Mobile Node）

CN（Correspondent Node）

内藤克浩，上醉尾一真，西尾拓也，水谷智大，鈴木秀和，渡邊 晃，森香津夫，小林英雄：

NTMobileにおける移動透過性の実現と実装，

情報処理学会論文誌，Vol.54, No.1, pp.380–393(2013).

DC NTM端末：MN

NTM

端末：

MN（移動後）

NAT

NTMobile

のトンネル通信 仮想IPアドレスによる通信

プライベートネットワーク

グローバルネットワーク



アプリケーションに仮想

アドレスを認識

►実IPアドレスの変化をアプリケーションから隠蔽

NTMobile の通信

3

実

アドレスによる カプセル

宛先：VIP

送信元：

^データ 上位層

IP層

（NTMbile）

下位層

カプセル化 デカプセル化

仮想IPアドレスに基づくパケット アプリケーションが認識しているコネクション

MN CN

VIP_CN

宛先：VIP

送信元：

^データ

宛先：VIP

送信元：

^データ

トンネル通信



アプリケーションに仮想

アドレスを認識

►実IPアドレスの変化をアプリケーションから隠蔽

NTMobile の通信

4

実

アドレスによる

カプセル ^データ 宛先：VIP

送信元：

上位層

IP層

（NTMbile）

下位層

カプセル化 デカプセル化

仮想IPアドレスに基づくパケット アプリケーションが認識しているコネクション

MN CN

VIP_CN

宛先：VIP

データ

送信元：

宛先：VIP

データ

送信元：

トンネル通信 仮想IPアドレスの管理について提案



仮想

アドレス

►実ネットワーク上で利用されないアドレス帯域から生成

⇒NTM端末がアドレス帯域からNTMobileの通信と一般の通信を判断



現状の仮想

アドレス管理方法

►DC毎に仮想IPアドレスプールを設定

⇒DCがNTM端末に一意な仮想IPv4アドレスを割り当てる

仮想 IP アドレスと現状の管理方法

NTM端末 5

DC_A DC_B

DC_A

のアドレスプール

仮想IPアドレス帯域

DC_B

のアドレスプール 割

り 当

て 仮想IPアドレス帯域から

仮想IPアドレスを

一意に割り当てる

仮想 IP アドレスの課題と研究の目的



アドレスプール調整による課題

►現状の管理方法では，DCに仮想IPアドレスプールを設定

⇒DC毎でアドレスプールの調整が必要



仮想IPv4アドレスの個数による課題

►

利用できる仮想

アドレス数が少ない（

万個ほど）

⇒NTMobileの普及を想定した場合，すべてのNTM端末に仮想IPv4

アドレスが割り振ることができない

6

仮想IPアドレスの管理方法を再検討し，仮想IPアドレスの課題を解決する

研究の目的

アドレス帯域

利用用途 アドレスの数

ネットワーク性能試験

仮想 IP アドレス管理方法の提案



仮想

アドレスの管理方法

►「NTM端末」が管理



「通信の識別」と「アドレス変換」による通信処理の拡張

⇒「アドレスプール調整による課題」「仮想IPv4アドレスの個数による課題」

を解決



仮想

アドレスの管理方法

►「DC」が管理



仮想IPv6アドレスのフォーマット・生成方法を提案

⇒「アドレスプール調整による課題」を解決

7



通信の識別

►NTMobileの通信は通信識別子Path IDのみで識別することが可能

Path ID

仮想 IPv4 アドレス管理方法

8

DC

NTM

端末：

端末：

Path ID MN - CN

Path ID MN - CN

通信開始時

DCが通信端末に対して配布

通信相手以外の

NTMobile

の通信を一意に識別する通信識別子（

）

MN CN

Path ID MN - CN



アドレス変換

►Path IDをもとに仮想IPv4アドレスの変換を行う

仮想 IPv4 アドレス管理方法

9

MN CN

Path ID MN - CN

アドレス 変換 アドレス

変換

宛先：A

送信元：

^データ

宛先：C

送信元：

^データ アドレス変換

宛先：

送信元：B

宛先：

送信元：D

仮想IPアドレスに基づくパケット

Path ID

通信をPath IDによって識別することで，

NTM端末内部で自由に仮想IPv4アドレス帯域を利用する事ができる

⇒「アドレスプール調整による課題」「仮想IPv4

アドレスの個数による課題」を解決

以上の手法により

仮想 IPv6 アドレス管理方法



仮想

のフォーマット

►仮想IPv6アドレスの上位64bitをネットワーク部，下位64bitをホスト部

と定義

►仮想IPv6アドレス帯域 ： 「 2001:db8::/32

」



文書作成用のアドレス帯域で，実ネットワークで利用されないことが

►DCのグローバルIPv4アドレスを付加

⇒DC毎の仮想IPv6アドレスプールを保証

►NTM

端末のユニーク

DC

内で一意な

の乱数

10

NTM端末のユニークID（64bitの乱数）

仮想IPv6帯域

ネットワーク部（64bit） ホスト部（64bit）

32bit 32bit

IANA：Internet Assigned Numbers Authority

仮想 IPv6 アドレス管理方法

11

NTM端末：A NTM端末：B NTM端末：C

DC_MN RIP4：RIP4_MN

DC_CN

RIP4：RIP4_CN

ID_A 2001

：

VIP6_A

ID_B 2001

：

VIP6_B ²⁰⁰¹

^：

毎でネットワーク部が異なるため，

アドレスプールの調整が不要

仮想IPv6アドレス内にDCのグローバルIPv4アドレスを付加することで，

DC

毎でのアドレス管理が可能となる

⇒「アドレスプール調整による課題」を解決

提案により

実装と性能評価



仮想

アドレス管理方法を実装



トンネル通信のスループットを測定

►ｉｐｅｒｆを用いたTCP通信を行い，MN～CN間のスループットを測定



スループットの低下率は

►アドレス変換の影響はほとんどないことを確認

12

400.4 402.5

0.0 100.0 200.0 300.0 400.0 500.0

提案方式あり 提案方式なし

Throughput[Mbps]

iperf

：ネットワークスループットを測定するためのソフトウェア

まとめ



仮想

アドレス管理方法の提案

►仮想IPv4アドレスの管理方法

Path ID

を元に仮想

アドレスの変換を行い，

端末毎で仮想

アドレスを管理

⇒「アドレスプール調整による課題」「仮想IPv4アドレスの個数による課題」

を解決

►仮想IPv6アドレスの管理方法



仮想

アドレスに

のグローバル

アドレスを付加し，

毎で仮想

アドレス管理

⇒「アドレスプール調整による課題」を解決



実装と性能評価

►仮想IPv4アドレスの管理方法の実装を行い，トンネル通信中のス

ループットを測定

⇒アドレス変換の影響はほとんどないことを確認

13