1. はじめに
IP通信では,端末が移動しても通信を継続できる移動透過 性とNATの存在に関わらず通信を開始できるNAT越え技 術は重要である.これら2つを同時に実現する手法として,
我々はNTMobile(Network Traversal with Mobility)[1]
を提案している.
しかし,NTMobileでは通信を行う両端末がNAT配下 に存在する場合に,直接通信可能な場合であっても後述す る第3の機器を用いた中継通信を行ってしまう.IPv4ネッ トワークでは通常NATを介した通信となるため,中継機 器の負荷増大やスループットの低下に繋がる.本稿では,
NTMobileに追加処理を行わせることにより,この問題を解 決する手法について検討する.
2. NTMobile
2. 1 NTMobileの動作概要
NTMobileを構成する機器として,NTMobileの機能を 有するNTMobile 端末,NTMobile端末を管理する DC
(Direction Coodinator),両NTMobile端末がNAT配下 に存在する場合や通信相手が一般端末の場合に通信を中継す るRS(Relay Server)がある.
NTMobile端末はネットワーク接続時に DCに対して 位置情報登録を行う.この時,NTMobile端末は DCか ら仮想IP アドレスを割り当てられ,上位アプリケーシ ョンは仮想IPアドレスで通信を識別する.NTMobile端 末(MN:Mobile Node)は通信開始時及び移動時にDCの 指示に従い通信相手NTMobile端末(CN:Corresponded Node),もしくはRSとの間にUDPトンネルを構築する.
アプリケーションは仮想IPアドレスを用いている為,移動 に伴うIPアドレスの変化を隠ぺいできる.また,UDPト ンネルを用いることで,通信経路上にNATが介在しても確 実に経路を構築できる.
2. 2 NTMobileにおける課題
NTMobileでは,両方の端末がNAT配下に存在する場 合,直接通信可能な場合であってもRSを経由する経路とな り,これは好ましくない.
また,MNとCNが同一のNAT配下に存在する場合,プ ライベートネットワークが多段NAT構成であると,NAT 越え問題によりMNとCN間で直接通信できない可能性が ある.DCはプライベートネットワーク内のネットワーク構 成を知ることができない為,RSを必ず経由させることでこ の問題を回避できるが,冗長な経路となる.
3. 提案方式
提案方式の動作概要を図1に示す.図は,MNがCNに 通信を開始するときの動作シーケンスである.網掛部分が
新たに変更・修正した部分である.提案方式では,RSとの 経路を構築した後,MNとCNが互いにパケットを投げ合 うことで直接通信可能であるかどうかを試みる.直接通信 可能であった場合には経路を更新する.第1処理では従来 のNTMobileと同様の処理を行い,RSを経由する通信経 路を構築する.この時点でMNはCNとデータパケット の送受信が可能となる.このとき,NATCNのポート番号 をAccess Check ResponseによってDCMNに通知する,
Route Directionには互いに通信相手のNATのポート番号 及び第2処理を行うための指示を含ませる.第2処理では,
エンド端末同士が互いにTunnel Requestを通信相手に送 信する.このメッセージを一方または両方のNTMobile端 末が受信した場合,RSを経由しないエンドエンドの通信経 路を確立する.両方のNTMobile端末がこのメッセージを 受信できなかった場合,RSを経由した通信が継続される.
また,提案方式をLinuxに実装し,経路が最適化されるこ とを確認した.
MN NATMN DNSMN DCMN RS DCCN NATCN CN
DNS Query for A
DNS Reply for A DNS Query for NTMobile
DNS Reply for NTMobile Direction Request
Access Check Request Access Check Response
Relay Direction Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet
Tunnel Request Tunnel Request
Tunnel Response Capsulated Packet
First NegotiationSecond Negotiation
図1: Sequence of proposed method
4. まとめ
本稿ではNTMobileを拡張し,通信を行う両端末がNAT 配下に存在しても直接通信を行うことが可能な方式を提案・
実装した.今後は,端末の移動時の仕様検討やIPv6におけ る動作の検討を行う予定である.
参考文献
[1] 内藤克浩,西尾拓也,水谷智大,鈴木秀和,渡邊晃,森香津 夫,小林英雄. NTMobileにおける移動透過性の実現と 実装.DICOMO2011, pp.1349 - 1359, 2011.
渡邊研究室 080425241 納堂 博史
提案と実装
• 移動通信の需要増加
公衆無線網の普及 小型携帯端末の普及
• 移動しながら通信を開始・継続する必要性
IP 通信では移動すると IP アドレスが変化
通信識別子である IP アドレスの変化に伴い IP 通信は切断
• NAT を跨る通信の必要性
IPv4 ネットワークでは一般に NAT を介する通信となる NAT の外側から通信を開始できない
はじめに
P-01
NAT を跨る移動透過性を実現する NTMobile の提案
NTMobile: Network Traversal with Mobility, NAT:Network Address Translation
NTMobile の概要
P-02 DC: Direction Coordinator, RS: Relay Server
仮想 IP アドレスの導入 UDP トンネル技術の利用
移動透過性 NAT 越え
Private Network
Internet
NAT
DC
RS 3G Network A
B C
NAT
仮想 IP アドレスの割当
トンネル構築指示
パケットの転送
NTMobile の概要
P-02 DC: Direction Coordinator, RS: Relay Server
仮想 IP アドレスの導入 UDP トンネル技術の利用
移動透過性 NAT 越え
Private Network
Internet
NAT
DC
RS 3G Network A
B C
NAT
仮想 IP アドレスの割当
トンネル構築指示
パケットの転送
NTMobile の概要
P-02 DC: Direction Coordinator, RS: Relay Server
仮想 IP アドレスの導入 UDP トンネル技術の利用
移動透過性 NAT 越え
Private Network
Internet
NAT
DC
RS 3G Network A
B C
NAT
仮想 IP アドレスの割当
トンネル構築指示
パケットの転送
NTMobile の動作シーケンス
P-03
• CN の名前解決をトリガとして UDP トンネルを構築
• トンネルを構築後, CN の仮想 IP アドレスをアプリケーションに通知
経路指示要求
経路指示 経路指示要求
経路指示 トンネル構築 トンネル構築
MN: Mobile Node, CN: Correspond Node
MN NATMN DCMN RS DCCN NATCN CN
Direction Request
Relay Direction Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet Name Resolution
NTMobile の動作シーケンス
P-03
• CN の名前解決をトリガとして UDP トンネルを構築
• トンネルを構築後, CN の仮想 IP アドレスをアプリケーションに通知
経路指示要求
経路指示 経路指示 トンネル構築 トンネル構築
MN: Mobile Node, CN: Correspond Node
MN NATMN DCMN RS DCCN NATCN CN
Direction Request
Relay Direction Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet Name Resolution
NTMobile の動作シーケンス
P-03
• CN の名前解決をトリガとして UDP トンネルを構築
• トンネルを構築後, CN の仮想 IP アドレスをアプリケーションに通知
経路指示要求
経路指示 経路指示要求
トンネル構築 トンネル構築
MN: Mobile Node, CN: Correspond Node
MN NATMN DCMN RS DCCN NATCN CN
Direction Request
Relay Direction Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet Name Resolution
NTMobile の動作シーケンス
P-03
• CN の名前解決をトリガとして UDP トンネルを構築
• トンネルを構築後, CN の仮想 IP アドレスをアプリケーションに通知
経路指示要求
経路指示 経路指示要求
経路指示 トンネル構築
MN: Mobile Node, CN: Correspond Node
MN NATMN DCMN RS DCCN NATCN CN
Direction Request
Relay Direction Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet Name Resolution
• DC は両端末が NAT 配下なら RS 経由の経路を指示
• RS を経由しなくて良い可能性有り
NTMobile で生成される冗長な通信経路
P-04
NAT
NAT MN
CN RS
NAT CN
RS
NAT MN
両端末が同一 NAT 両端末が異なる NAT
• DC は両端末が NAT 配下なら RS 経由の経路を指示
• RS を経由しなくて良い可能性有り
NTMobile で生成される冗長な通信経路
P-04
NAT
NAT MN
CN RS
NAT CN
RS
NAT MN
両端末が同一 NAT 両端末が異なる NAT
• DC は両端末が NAT 配下なら RS 経由の経路を指示
• RS を経由しなくて良い可能性有り
NTMobile で生成される冗長な通信経路
P-04
NAT
NAT MN
CN RS
NAT CN
RS
NAT MN
両端末が同一 NAT 両端末が異なる NAT
• 端末間で直接制御パケットを投げ合う
どちらかの端末で受信できれば経路を最適化
• RS 経由の通信経路構築後に最適化
最適化できない場合も通信の継続が可能
• アプリケーションの通信と並行して最適化
RS 経由の通信経路構築後すぐに通信が可能
NTMobile の経路最適化
P-05
提案方式の動作シーケンス( 1 )
P-06 NAT
CNの
ポート番号取得
MN NAT
MNDC
MNRS DC
CNNAT
CNCN
Direction Request
Access Check Request Access Check Response
Relay Direction Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet
ポート番号通知 MN宛:NAT
CNCN宛:NAT
MN• MN と CN で互いにパケットを投げ合う
パケットをどちらか片方でも受信したら最適化
提案方式の動作シーケンス( 2 )
P-07 経路更新
経路更新
MN NAT
MNNAT
CNCN
Tunnel Request Tunnel Request
Tunnel Response Capsulated Packet
RS
• 経路最適化モジュール
パケットの投げ合い , トンネルテーブルの更新
• アクセス制御モジュール
ポート番号の取得 / 格納
経路最適化の実装
P-08
NTMobile
カーネルモジュール NTMobileデーモン
トンネル構築モジュール 経路最適化モジュール
NTM 端末 DC
NTMobileデーモン
トンネル構築モジュール アクセス制御モジュール
経 路 指示 関数 その
他 の関 数
• 評価方法
スループット測定
EN A から EN B に FTP 転送 (1GB) 最適化の有無で比較
性能評価
P-09
ENA ENB
NAT Router
100BASE-T
100BASE-T
DCA DCB RS
Device OS CPU Memory
DC Ubuntu 10.04
Core 2 Duo P9400
2.4GHz 1.9GB
RS Ubuntu 10.04
Core 2 Duo E6600
2.4GHz 2.0GB
EN Ubuntu 10.04
Core 2 Duo U9400
1.4GHz 1.8GB
各機器の仕様 ネットワーク構成
評価結果
P-10
RS NAT
Data
CN MN
3.94ms
最適化 10.83MB/s
RS経由 5.02MB/s 最適化に
要する時間 ス
ル ー
プ ッ
ト
アプリケーションデータ
最適化シーケンス
• NTMobile で通信経路が冗長になる問題
両端末が NAT 配下に属する場合に冗長経路が構築される
• 課題の解決
直接通信が可能な場合の経路最適化を提案 - 端末間で互いに Tunnel Request を投げ合う - 上記で直接通信可能かを判断
-Tunnel Request/Response を受信すると経路が更新される
• 今後の予定
端末移動時の経路最適化の検討
端末がそれぞれ異なる NAT 配下の場合の性能評価
まとめ
P-11
補足資料 (NTMobile のパケット )
補-01
MN CN
TO:RIPCN
From:RIPMN
TO:VIPCN
From:VIPMN Data
Encrypt
TO:VIPMN
From:VIPCN Data
TO:RIPCN
From:RIPMN
TO:VIPCN
From:VIPMN Data
Decrypt
TO:VIPCN
From:VIPMN Data
TO:RIPCN
From:RIPMN Capsulated Data TO:RIPCN
From:RIPMN Capsulated Data
IP Layer
Real IP Address: RIPMN
Virtual IP Address: VIPMN
Real IP Address: RIPCN
Virtual IP Address: VIPCN
New Header New Header
実IPアドレス オリジナルパケット
仮想IPアドレス データ
補足資料 (NTMobile の NAT 越え )
補-02
Private Network
WAN NAT LAN
CN:4330 NAT:1000 MN:4330
MN To=CN:4330
From=MN:4330 To=CN:4330
From=NAT:1000
CN To=NAT:1000 From=CN:4330
To=MN:4330 From=CN:4330
Private Network
WAN NAT LAN
MN CN
To=NAT:4330 From=CN:4330
NAT 越え問題
NAT 越え手法
NAT エントリ未生成
→WAN 側からアクセスできない
NAT エントリを事前に生成
→LAN からパケット送信
(Tunnel Request)
補足資料 ( 経路最適化の NAT 越え )
補-03
Private Network Private Network
WAN NATMN LAN
DCMN:4330 NATMN:100 MN:4330
MN
Dst=DCMN:4330 Src=MN:4330 Dst=DCMN:4330
Src=NATMN:100 Dst=NATMN:100 Src=DCMN:4330
Dst=MN:4330 Src=DCMN:4330
CN
WAN NATCN LAN
DCCN:4330 NATCN:200 CN:4330
DCMN
DCCN
Dst=DCCN:4330 Src=CN:4330
Dst=DCCN:4330 Src=NATCN:200 Dst=NATCN:200 Src=DCCN:4330 Dst=CN:4330
Src=DCCN:4330
WAN NATMN LAN
DCMN:4330 NATMN:100 MN:4330 NATCN:200 NATMN:100 MN:4330
WAN NATCN LAN
DCCN:4330 NATCN:200 CN:4330 NATMN:100 NATCN:200 CN:4330
Dst=NATMN:100
Src=CN:4330
Dst=NAT
MN:100,Src=NAT
CN:200Dst=NAT
CN:200,Src=NAT
MN:100Dst=CN:4330 Src=DCCN:4330
Dst=NATCN:200 Src=MN:4330
補足資料 ( 経路最適化の並行処理 )
補-04
RS NAT
Tunnel Request Tunnel Response
SYN
SYN,ACK ACK
FTP Data
Optimized Optimized
CN MN
Capsulated Packet
CN MN
Tunnel established via RS