NTMobile における自律的経路最適化の提案
納堂 博史 1,a) 鈴木 秀和 1,b) 内藤 克浩 2,c) 渡邊 晃 1,d)
受付日
24
年4
月16
日,
採録日24
年10
月12
日概要：モバイルネットワークの普及により，どのようなネットワーク環境においても通信の開始が可能な 通信接続性と，通信しながらネットワークの切り替えが可能な移動透過性が求められている．我々は，通 信接続性と移動透過性を同時に実現する
NTMobile
（Network Traversal with Mobility
）を提案している．NTMobile
では通信を行う両エンド端末が共にIPv4
のNAT
配下に存在する場合には，リレーサーバを経由する通信経路を構築する．
IPv4
ネットワークでは，端末はNAT
配下に存在することが多いため，中継 機器の負荷増大，及び冗長な経路によるスループットの低下が生ずる．そこで，本論文ではNTMobile
に おいて，両エンド端末がNAT
配下に存在していても，端末間で直接通信可能であれば自律的に最適経路 に切り替える手法を提案する．提案方式をLinux
に実装し，従来のNTMobile
と比べてスループットが向 上することを確認した．キーワード：
NAT
越え問題，路最適化，通信接続性，移動透過性A Proposal of Autonomous Route Optimization in NTMobile
Nouduo Hiroshi 1,a) Suzuki Hidekazu 1, b) Naito Katsuhiro 2,c) Watanabe Akira 1,d)
Received: April 16, 24, Accepted: October 12, 24
Abstract: With the spread of mobile networks, connectivity which the beginning of communication is pos- sible between any kinds of networks, and mobility which the switching of networks is possible during com- munication become quite important matters. We have been proposing NTMobile (Network Traversal with Mobility) that can achieve both connectivity and mobility at the same time. However, in NTMobile, if both end terminals exist behind NATs, they definitely create the route via a Relay Server, which impose exces- sive loads on the Relay Servers and networks. In this paper, we propose autonomous route optimization in NTMobile when there exists an optimized route. We have implemented the proposed system and confirmed its effectiveness.
Keywords: NAT traversal problem, route optimization, connectivity, mobility
1. はじめに
高速無線通信技術の発展とスマートフォンをはじめとす る携帯端末の普及により，携帯端末からインターネット への接続が増加している．このような環境では，通信相手 に対して必ず通信経路を確立できることを保証する通信
1
名城大学理工学部情報工学科Department of Information Engineering, Meijo University
2
三重大学大学院工学研究科Graduate School of Engineering, Mie University
a) [email protected]
b) [email protected]
c) [email protected]
d) [email protected]
接続性は極めて重要である．また，通信中に携帯電話網か ら Wi-Fi などに適切にトラフィックを迂回したり， Wi-Fi ネットワーク内を自由に移動できる移動透過性技術の重要 性が高まっている．本論文では， IPv4 が今後も主要なプロ トコルとして存在し続けることを前提に， IPv4 におけるこ れらの課題について議論する．
IPv4 ネットワークの最大の課題としてグローバルアド
レスの枯渇問題があげられる．そこで，組織のネットワー
クをプライベートアドレスで構築し，インターネットと
の接続は NAT （ Network Address Translation ）を経由す
ることが一般的である．このようなネットワーク構成で
は，インターネット側から NAT の内側に向けて通信を
開始できない NAT 越え問題が存在し，通信接続性が確保 できないという大きな課題がある． NAT 越えを実現する 既存技術として STUN (Simple Traversal of UDP through NATs)[1] ， TCP hole punching[2] ， TURN (Traversal Using Relay NAT)[3] ， ICE (Interactive Connectivity Establish- ment)[4], [5] ， NAT-f (NAT-free protocol)[6] などが提案さ れている． STUN ， TCP hole punching ， TURN ， ICE は NAT に改造を加えずに NAT 越えを実現する技術である が，アプリケーションがこの技術に対応している必要があ る． NAT-f は，外部ノードが NAT とネゴシエーションを 行うことにより， NAT にマッピング処理を行わせ NAT 越 えを実現するが，通信開始ノードと NAT が NAT-f に対応 している必要がある．これらの技術はいずれも端末の移動 を考慮していないため，単独では以下に述べる移動透過性 を実現することができない．
一方， IP ネットワークは通信中にネットワークの切り替 えなどにより IP アドレスが変化すると，通信識別子 *1 も 同時に変化し，移動透過性を実現できない．移動透過性を 可能とするために様々な研究が行われてきたが， IPv6 対応 の方式が主流である [7], [8], [9] ．その理由は，今後の主流 が IPv6 になることを期待していたこともあるが， IPv4 で は NAT が存在するために，自由な移動が技術的に難しい という課題があったことも否めない．
IPv4 ネットワークで移動透過性を実現する技術として，
これまで Mobile IPv4[10] ， MATv4 (Mobile Support Ar- chitecture and Technologies v4)[11] ， Mobile PPC (Mobile Peer to Peer Communication)[12] などが提案されてきた．
MATv4 は， NAT が存在すると通信接続性が実現できず，
NAT を跨る移動はできない． Mobile IPv4 では NAT を跨 る移動をするために， NAT に HA （ Home Agent ）の機能 を持たせる方法が検討されている [13], [14] ．しかし， NAT の改造が必要となるため移動範囲が限定されるという課題 がある．
Mobile PPC は， IPv4 においてアドレス変換を駆使する ことにより、エンドエンドの装置だけで移動透過性を実現 できることを特徴としている． Mobile PPC において NAT が含まれる環境でエンド端末のみによる移動透過性を実現 するには， NAT を改造するか，新たな通信シーケンスを 定義して NAT のアドレスをエンド端末に伝えるなどの処 理が必要になる．文献 [15] は，前者の方式に対応したもの で，通信相手端末 CN 側の NAT を改造して NAT-f の機能 を保持させることにより実現している．しかし，この方法 は CN が特殊な NAT 配下にいることが前提となり，システ ム構成が限定されることになる．後者の方法は，アドレス 変換処理が極めて複雑となり現実的ではない．このように
*1
宛先IP
アドレス，送信元IP
アドレス，宛先ポート番号，送信 元ポート番号，プロトコル番号（TCP
，UDP
の区別）の5
つの 情報で決まる．Mobile PPC をベースとした移動透過性にも限界があった．
我々は，上記課題を解決することを目的とし，あらゆる ネットワーク環境での通信接続性と移動透過性を同時に 実現する技術として， NTMobile （ Network Traversal with Mobility ） [16], [17], [18], [19], [20], [21], [22] を提案してい る． NTMobile はアドレス変換技術でなく，仮想アドレス の導入とトンネル技術を用いることにより移動透過性を実 現した技術である． NTMobile では，各通信端末に仮想 IP アドレスが割り振られ，アプリケーションはこのアドレス を通信識別子として利用する．実際の通信は，仮想アドレ スで生成された上記パケットを実 IP アドレスでカプセル 化して実現する．そのため，アプリケーションは NAT に伴 うアドレス変換や，ネットワーク切り替えに伴う実 IP アド レスの変化を一切意識する必要がない． NTMobile による と， NAT を含むネットワーク機器を一切変更する必要がな い．また，通信経路上に NAT が 2 個以上存在する場合に おいても通信接続性を保証することができる． NTMobile は， DC(Direction Coodinator) や RS(Relay Server) と呼 ぶ装置をグローバルネットワーク上に設置する必要がある が， IPv4 における通信接続性と移動透過性を確実，かつシ ンプルに実現できる．
NTMobile では，端末を管理する DC が端末に対してト ンネル経路の構築を指示する． NAT が存在する場合には，
NAT 配下から通信相手端末に向けて直接トンネル経路を 構築するよう指示する．そのため， NTMobile は経路最適 化機能を基本機能として備えている．通信端末がいずれも NAT 配下に存在する場合には，確実に経路を生成するため RS を経由する経路を指示する．これは， DC が NAT の種 別を判別したり， NAT 配下のネットワーク構成を把握する ことができないためである．しかし，実際には RS を介さ なくとも通信が可能な場合がある．その理由は， NAT 配 下の端末から何らかのパケットが NAT を通過すると，そ れに対応した NAT テーブルが生成されるが， NAT の種別 によってはそのテーブルを用いて NAT 外部から通信が可 能になるためである．また，両エンド端末が同一の NAT 配下にいる場合においては， NAT が多段構成でない限り，
NAT を介さない直接の通信経路が存在する． RS を経由す ると，冗長な経路によるスループットの低下，パケット遅 延の増大， RS の負荷増大，ネットワーク負荷の増大など が生ずる懸念があるため，できるだけ通信端末間で直接通 信を行えることが望ましい．
本論文では，両通信端末がいずれも NAT 配下に存在す る場合に，オリジナル NTMobile による経路構築完了後，
通信端末側で更なる経路最適化を実現する自律的経路最
適化を提案する．具体的には， RS を経由する通信経路が
構築された後，通信端末が互いに通信相手に向けて制御パ
ケットを投げ合うことにより直接通信ができるかどうかを
判断する．直接通信可能と判断した場合には，端末間で経
NAT Router
DCA
DCB
RSA
RSB 3G Network
NTM Node 1 managed by DCA
NTM Node 2 managed by DCB NTM Node 4
managed by DCA
NAT Router
DC RS
Encrypted Communication Through UDP Tunnel Direction Coordinator Relay Server
General Communication
General ServerNAT Router
NTM Node 3 managed by DCB
図
1 NTMobile
の構成Fig. 1 Overview of NTMobile system.
路を最適化する．直接通信が不可能と判明した場合には，
RS を経由した通信を継続する．この方法により， NAT の 特性やネットワーク構成に合わせた最適経路での通信が可 能となった．提案方式を Linux に実装し，動作確認及び性 能評価を行い，自律的経路最適化の効果を確認した．
以下， 2 章で NTMobile の概要， 3 章で自律的経路最適 化の提案， 4 章で実装と評価結果を示し， 5 章でまとめる．
2. NTMobile
本章では，提案方式の基礎技術となる NTMobile につい て説明する．なお， NTMobile に係る文献とその内容を付 録に示す．
2.1 NTMobile
の構成図
1 に NTMobile の構成を示す． NTMobile では， NT- Mobile の機能を有する端末（ NTM 端末） ，仮想 IP アドレ スの管理や NTM 端末に対してトンネル経路構築の指示を 出す DC ， NTM 端末どうしが直接通信できない場合に通 信を中継する RS から構成される． DC どうし， DC と RS 間，および NTM 端末と DC 間は信頼関係があることを前 提とする．
各 NTM 端末は，起動時に DC に対して実 IP アドレスな ど必要な情報を登録するとともに， DC から重複しないこ とが保証された仮想 IP アドレスが割り当てられる． NTM 端末のアプリケーションは仮想 IP アドレスを用いて通信 セッションを確立する． NTM 端末は，仮想 IP アドレス で生成された IP パケットを，カーネル空間において実 IP アドレスで UDP カプセル化して通信を行う．この方法に よると，通信中に NTM 端末の実 IP アドレスが変化して も，仮想 IP アドレスは変化しないため移動透過性を実現 できる．また， NAT が存在する場合は， DC の指示によっ て NAT の内側からトンネル経路が生成されるため， NAT
越え問題を解決できる．移動の前後において通信経路上に NAT が存在しても構わない．
DC は複数の設置が可能であり，それぞれの DC には予 め異なる仮想 IP アドレス空間が割り当てられている．各 DC は自らが保有するアドレス空間内で，重複しないよ うに NTM 端末に対して仮想 IP アドレスを割り当てる．
DC は Dynamic DNS の機能を包含しており， NTM 端末 のアドレス情報は Dynamic DNS の A レコード，および NTMobile 専用レコードとして登録および更新される．通 信相手の情報は NTM 端末が自身のプライマリ DNS に問 い合わせることにより取得できる． NTMobile レコードと しては， NTM 端末のホスト名（ FQDN ） ，実 IP アドレス，
仮想 IP アドレス， NAT の外側の実 IP アドレス， DC の 実 IP アドレス，および NTM 端末を一意に識別する Node ID が定義されている．
RS には，通信を行う NTM 端末がそれぞれ異なる NAT 配下に存在する場合にパケットの中継を行うスイッチタイ プ，通信相手が NTMobile の機能を持たない一般端末の場 合に通信パケットの中継を行うアドレス変換タイプがある．
スイッチタイプの場合， RS はそれぞれの NTM 端末とト ンネルを構築し，トンネルを切り替えることによりパケッ トを中継する．アドレス変換タイプの場合， RS と NTM 端末間でトンネルを構築し， RS が自身の実 IP アドレスを 用いて一般端末と通信を行う．一般端末は通信相手が常に RS に見えるため， NTM 端末側は自由に移動できる． RS は DC と同様に複数の設置が可能であり，どの RS を使用 するかは DC が判断する．なお，本論文での議論はスイッ チタイプの RS に係るものである．
2.2
動作シーケンス以後の説明では，通信開始側の NTM 端末を MN （ Mo- bile Node ） ，通信相手側の NTM 端末を CN （ Correspondent Node ） ， NTM 端末 X を管理する DC を DC X ， NTM 端末 X の実 IP アドレスと仮想 IP アドレスをそれぞれ RIP X ， VIP X とする．
2.2.1
端末情報の登録MN はネットワークに接続するときに，自身の実 IP ア
ドレスなどの端末情報を DC MN に登録する．登録情報は
RIP MN ， VIP MN ， MN の Node ID ，および MN の FQDN
である． DC MN は登録用制御パケットを受信したとき，パ
ケットの送信元アドレスとメッセージ内のアドレスを比較
することにより， MN が NAT 配下に存在するかどうかを
判別する． NAT 配下であった場合には IP ヘッダのアドレ
スより NAT ルータの IP アドレスを取得する．これらの
情報は DC の Dynamic DNS 機能により NTMobile レコー
ドとして登録される． MN の端末情報登録終了後， DC MN
は MN に対して仮想 IP アドレスを通知する．
MN NAT MN DC MN RS DC CN NAT CN CN Direction Request
Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet Relay Direction Relay Response
図
2
トンネル構築の動作シーケンスFig. 2 Sequence of Tunnel establishment.
2.2.2
名前解決MN は CN と通信を開始するとき， CN の名前解決の為 にプライマリ DNS に対して A レコードの問い合わせを行 う． MN はこれに対する DNS 応答をカーネルでフックし て一時的に退避させておき，プライマリ DNS 経由でさら に CN の NTMobile 専用レコードを問い合わせる． CN の 専用レコードが取得できた場合は， CN が NTM 端末であ り，取得できなかった場合は， CN が一般端末であること がわかる．このように既存の DNS のしくみの中で CN 側 の情報を取得できる．
2.2.3
トンネル構築図
2 にトンネル構築シーケンスの例を示す．このシー ケンスは，通信開始時には名前解決が終了した直後に，通 信中に MN のアドレスが変化した時には， IP アドレス取 得直後に実行される．図 2 は， MN と CN がその時点で それぞれ異なる NAT 配下に存在する場合の例を示してい る． MN は DC MN に対して経路指示を要求する Direction Request を送信する． Direction Request には MN と CN の NTMobile レコードの情報が含まれている． DC MN は これらの情報を元に， MN と CN の位置を判断し，トンネ ル構築の指示内容を決定する．図 2 の例では， MN と CN がいずれも NAT 配下に存在するため， RS を経由する通信 を行うべきと判断する． DC MN は RS との間でパケットの 中継を指示する Relay Direction/Relay Response のやり取 りを実行後， MN と CN に対して RS とのトンネル構築を 指示する Route Direction を送信する．なお， CN に送信 する Route Direction は DC CN を経由させる． CN が移動 して新しい IP アドレスを取得したとき， CN から DC CN に端末情報の登録を行う．このため， CN と DC CN は常に 経路を確立しており， DC CN からのパケットは CN に到達 できる．
MN と CN は Route Direction を受信すると， RS との トンネルを構築するため，それぞれ指示された RS に対し て Tunnel Request を送信する． Tunnel Request によって NAT MN 及び NAT CN の NAT テーブルにそれぞれ RS と
NAT
MCMN CN
RS
NAT
CNCN RS
NAT
MNMN
Optimal Path Redundant Path
(a)構成１：異なるNAT配下 (b)構成２：同一のNAT配下
図
3
冗長な通信経路となるネットワーク構成Fig. 3 Network configuration of redundant communication paths.
の通信用のエントリが生成される． Tunnel Request を受信 した RS は Tunnel Response を返信し，トンネル構築が完 了する． MN は Tunnel Response を受信すると，退避させ ていた DNS 応答に記載されている RIP CN の値を VIP CN に書き換え， DNS リゾルバに渡す．これにより， MN のア プリケーションは CN の IP アドレスを VIP CN と認識して 通信を開始する．
なお， NTMobile を構成する機器間で送受信される制御 メッセージ，およびカプセル化されるパケットは暗号化と 認証が施され，第三者による盗聴の防止や改ざんの検出が 可能である．
3. 自律的経路最適化
本章では自律的経路最適化の原理と実現方式を述べる．
以下に示す手順は，通信開始時，および通信中に IP アド レスが変化した時の両者に対して全く同様に適用できる．
3.1
通信経路の冗長問題通信経路が冗長となるケースとして，以下の 2 通りがあ る．図 3 に，構成 1 として MN と CN がそれぞれ異なる NAT 配下に存在する場合，構成 2 として MN と CN が同 一 NAT 配下に存在する場合の例を示す．
構成 1 ：異なる NAT 配下の場合
MN と CN がそれぞれ異なる NAT 配下に存在する場 合， DC は確実に経路を生成するため， RS 経由の通信 経路を指示する．しかし， NAT の種類によっては図 に示すように RS を経由せずに通信できる場合がある．
NAT 配下から何らかのパケットが NAT を通過したと きに， NAT に NAT テーブルが生成されるが， NAT の種類によっては，この NAT テーブルを用いて NAT 外部からの通信開始ができるためである．
構成 2 ：同一 NAT 配下の場合
MN と CN が同一 NAT 配下に存在する場合， DC は
NAT 配下の構成がわからないため，最適な経路指示
を出せない．そこで，確実に経路を生成するため， RS
経由の通信経路を指示する．しかし，実際には図に示
すような最適経路が存在することが多い．
3.2 NAT
の種別現存する NAT 機器は NAT のマッピング特性とフィル タリング特性の違いにより以下のように分類できる．な お，ここで述べる NAT は，正確にはポート番号も変換す る NAPT （ Network Address Port Translation ）のことで ある．マッピング特性とは， NAT 配下の端末からのパケッ トが NAT を通過した際に， NAT に生成されるマッピング 生成規則のことを指す．具体的には，外部端末によらず同 一のテーブルを生成するタイプ，外部端末のアドレス単位 にテーブルを生成するタイプ，アドレス / ポート単位にテー ブルを生成するタイプがある．フィルタリング特性とは，
外部端末から NAT 宛てのパケットを受信したときのフィ ルタリングの方法を指す．具体的には，外部端末によらず パケットを通過させるタイプ，外部端末のアドレス整合性 をチェックするタイプ，外部端末のアドレス / ポートの整合 性をチェックするタイプがある．これらの分類とその名称 の関係を表 1 に示す．なお，この名称は文献 [23] に従った ものである． Full Cone, Restricted Cone, Port Restricted Cone, Symmetric の順に制約が大きくなる．
表
1 NAT
の分類Table 1 Classification of NATs.
フィルタリング特性 外部端末に よらず通過
アドレス整合性 をチェック
アドレス/ポート 整合性をチェック マッピング
生成規則
外部端末によらず同一
Full Cone Restricted Cone Port Restricted Cone
アドレス単位Symmetric
アドレス/ポート単位構成 1 における NAT MN ， NAT CN のいずれもが Sym- metric 型 NAT である場合は経路最適化はできない．これ 以外の場合は，今回提案する方式により経路最適化できる 場合がある．文献 [2] の調査報告によると，市場に出回っ ている NAT 装置の 82% がいずれかの Cone 型 NAT であっ たとされており，構成 1 においても経路最適化ができる可 能性が高い．
構成２においては， NAT MC と MN 間， NAT MC と CN 間に別の NAT がそれぞれ存在すると， NAT の種別に係ら ず経路最適化はできない．これは，投げ合うパケットの宛 先がわからないためである． MN と CN の通信経路上に，
NAT が存在しないか１台以下である場合は，どちらかの NTM 端末の送信したパケットが通信相手に届くので，通 信経路上の NAT の種別に係らず経路最適化ができる．
3.3
自律的経路最適化の実現手段提案方式では，まず DC の指示通りに RS 経由の通信経 路を構築する．次に RS 経由の通信を行いながら，並行し て最適経路が存在するかどうかを判断し，存在すればト ンネル経路を切り替える．最適経路の有無の判断には MN
MN NAT
MNDC
MNRS DC
CNNAT
CNCN
Direction Request
Relay Direction
Route Direction Route Direction
Tunnel Request Tunnel Request
Tunnel Response Tunnel Response
Capsulated Packet
Autonomous Tunnel Request Autonomous Tunnel Request
Autonomous Tunnel Response
Tunnel establishment via RSRoute optimization
b c a
Behind NAT NAT Outside of NAT MN:4330 NATmn:4330 DCmn:4330 MN:4330 NATmn:4330 RS:4330
NAT
MNBehind NAT NAT Outside of NAT CN:4330 NATcn:4330 DCcn:4330 CN:4330 NATcn:4330 RS:4330
NAT
CNMN:4330 NATmn:4330 DCmn:4330 MN:4330 NATmn:4330 RS:4330 MN:4330 NATmn:4330 NATcn:4330
CN:4330 NATcn:4330 DCcn:4330 CN:4330 NATcn:4330 RS:4330 CN:4330 NATcn:4330 NATmn:4330
a b
c Capsulated Packet
Same as above
Same as above Relay Response
図
4
自律的経路最適化の動作シーケンスFig. 4 Sequence of Autonomous Route Optimization for NT- Mobile.
と CN が互いに制御パケットを投げ合い，このパケットを 受信できた時点で経路切り替えが可能と判断する．制御パ ケットに到達性がない場合は， RS を経由しないと通信が できないものと判断し，既に構築されている RS 経由の通 信を継続する．
自律的経路最適化の動作は， NTMobile の基本動作に追 加処理を行わせることにより実現する．図 4 に構成 1 の 場合を例にとって，自律的経路最適化の動作シーケンスを 示す．構成 2 においても全く同様のシーケンスを適用で きる．網掛け部分が経路最適化のために追加・修正された シーケンスである．まず， MN は NAT CN の IP アドレス / ポート番号を， CN は NAT MN の IP アドレス / ポート番号 を知っておく必要がある． NAT の IP アドレスについて は，すでに NTMobile レコードとして定義済みである．そ こで， NAT のポート番号を NTMobile レコードとして新 たに追加定義した．これにより，名前解決時に上記情報を 取得することができる．次に， DC MN は MN 宛ての Route Direction に NAT CN のポート番号を， CN 宛ての Route Direction には NAT MN のポート番号を追加情報として格 納して送信する． Route Direction を受信した MN と CN は，図 2 と同様に DC MN の指示に従って RS との経路を 構築する． MN と CN はこの経路を使用して，カプセル化 通信を開始する．
以上の処理で DC は役割を終え，以後は MN と CN が
自律的に経路最適化を試みる． MN と CN は互いに Au-
tonomous Tunnel Request を通信相手の NAT 宛てに送信
する．図 4 は NAT MN と NAT CN がともに Port restricted
NAT の場合の NAT テーブルの変化を示している．表中 の記号の意味は， IP アドレス：ポート番号であり， 4330 は NTMobile 用に定義された制御パケットのポート番号で ある． CN から最初に送信される経路最適化のための Au- tonomous Tunnel Request が通過することにより， NAT CN に NAT MN との通信用の NAT エントリが生成される（図 中の b 点） ．このパケットが NAT MN に到達する時点では 送信元が NAT CN ，宛先が NAT MN のアドレスとなる．こ の時 NAT MN の NAT エントリには， NAT CN との通信用の エントリがまだ生成されていないため，上記パケットは廃 棄される．次に MN から送信される Autonomous Tunnel Request が通過することにより， NAT MN にも NAT CN と の通信用 NAT エントリが生成される（図中の c 点） ．この パケットは NAT CN の 3 行目の NAT エントリを利用して NAT を通過し， CN に到達する．このように両 NAT にお 互いの NAT エントリが生成されると，以後の通信は直接 経路で可能である．なお， NAT MN が Full Cone 型の NAT の場合は，最初の Autonomous Tunnel Request が，廃棄さ れることなく NAT を通過し MN に到達する． MN と CN は Autonomous Tunnel Request を 3 回まで繰り返し，パ ケットの到達性があるかどうかを試みる．構成 1 の場合 は， Autonomous Tunnel Request は相手 NAT 宛に送信を 試みるが，構成 2 の場合は相手 NTM 端末宛に送信を試み る．構成 1 と構成 2 の違いは DC が把握できるので， MN と CN は DC からの指示内容により処理の切り替えを行う．
なお， Autonomous Tunnel Request/Autonomous Tunnel Response のパケットの内容は， Tunnel Request/Tunnel Response と全く同様である．
提案方式は， MN と CN が制御パケットを投げ合うこ とにより最適経路を探すという点で文献 [2] の手順と類似 点がある．しかし，文献 [2] と既存の移動透過性技術を単 純に組み合わせただけでは， TCP において近年の NAT に対応できない．近年の NAT には SPI (Stateful Packet Inspection) と呼ぶ強力なフィルタリング機能を有するこ とが多い．この機能があると， MN が TCP 通信中に NAT 配下に移動すると， NAT にとっては TCP 通信が途中から 始まったように見えるため，不正通信として扱われパケッ トは廃棄される． NTMobile では，すべての通信パケット を UDP でカプセル化するため， SPI による TCP 整合性 チェックを回避することができる．
4. 実装と評価
NTMobile の基本動作は Linux において既に動作が検証 されている．そこで，検証済みのモジュールに以下に示す 追加，および改良を施した．
4.1
各機器のモジュール構成図
5 に NTMobile を構成する各機器のモジュール構成
を示す．
DC のモジュール構成
DC はユーザ空間で動作する NTMobile デーモンと，
NTMobile レコードを扱うことができるように拡張 した DNS サーバ（ BIND ）で構成される． NTMobile デーモンには自身が管理する NTM 端末の情報を格納 するノードテーブルがある．
RS のモジュール構成
RS はユーザ空間で動作する NTMobile デーモンで構 成される． NTMobile デーモンは DC からの中継指示 の処理や NTM 端末とのトンネル構築を行う． RS は パケットの転送に必要な情報をリレーテーブルに保持 している． RS はカプセル化されたパケットを受信す ると，リレーテーブルを参照してカプセルヘッダの付 け替えを行い，対となる端末に転送する． RS 機能は 本来はカーネルで実装する予定であるが，今回は提案 方式の検証を目的としてデーモン側に実装を行った．
NTM 端末のモジュール構成
NTM 端末はユーザ空間で動作する NTMobile デーモ ンとカーネル空間で動作する NTMobile カーネルモ ジュールで構成される． NTMobile デーモンは DC へ の NTM 情報の登録と仮想アドレスの取得，および DC の指示に従ったトンネル構築を行う．カーネルモ ジュールはパケットのカプセル化 / デカプセル化及び暗 号化処理を行う． NTMobile デーモンには新たに経路 最適化モジュールを追加実装し，経路最適化のパケッ トの送受信やトンネルテーブルの操作を行うようにし た．トンネル構築モジュールには経路構築後，経路最 適化モジュールを呼び出す処理を追加した．経路最適 化処理は自律的経路最適化が終了するか， Autonomous Tunnel Request を 3 回送信しても応答がない場合に最 適化ができなかったものと判断して処理を終了する．
4.2
動作検証構成 1 ，構成 2 と同様のプロトタイプシステムを構築し動 作を検証した．図 6 に試験ネットワーク構成を示す． NAT には Port restricted NAT を使用した． NAT の外側はイン ターネットを想定し Dummynet を設置した． Dummynet の設定値は，実測値に基づき，遅延を 10ms ，パケットロス 率を 0.05% とした．検証方法は， CN に FTP サーバを構築 し， MN から FTP サーバに接続を行った．
図
7 に構成 2 において実行された自律的経路最適化動作 を，ネットワークモニタを用いてキャプチャした様子を示 す．図 7 は RS に対する Tunnel Request を送信した時点 からの様子を示している． MN と CN が RS とのトンネル を構築した後， MN から CN に RS 経由で TCP の最初の 通信パケットとなる SYN が送信されていることがわかる．
これと並行して， MN と CN の間で Autonomous Tunnel
Packet Flow Operation Flow
Real I/F
NTMobile Daemon
Tunnel Establishment BIND
DNS Server
Direction Request Route Direction Relay Direction
User Space Kernel Space
Added Module
(a) Direction Coordinator
Real I/F NTMobile Daemon
Tunnel
Establishment Relay Module Search Table
Capsulated Message Relay Direction Tunnel Request Tunnel Response
Relay Table
User Space Kernel Space
(b) Relay Server
Real I/F
NTMobile Daemon Tunnel Establishment
DNS
NTM Query DNS
Resolver Route
Optimization
Aplications
User Space Kernel Space
NTMobile Kernel Module
Tunnel Table Packet
Manipulation
Virtual I/F Direction Request
Route Direction Tunnel Request Tunnel Response
DNS Query (NTM Records )
Received DNS Query
Response (A record )
Create Table
Update Table
Tunnel Request Tunnel Response
Netlink Socket Peer’s Virtual IP (Modified DNS Query )
Search Table
Peer’s Virtual IP
TCP/UDP Packet (Src/Dst = Real IP)
TCP/UDP Packet (Src/Dst = Virtual IP )
Netfilter Netfilter
(c) NTMobile Node
図
5 NTMobile
のモジュール構成Fig. 5 Module configurations of NTMobile.
Request/Autonomous Tunnel Response の処理が行われて いる．図 7 では MN と CN の双方から最適化処理が開始 されているが， MN から開始した処理が先に終了し，この 時点で経路切り替えが完了した．最適化処理に要した時間 は， 3.96ms であった．すなわち， 1 回目の通信パケットが RS 経由で相手端末に到達する前に自律的経路最適化が終 了し，以後のパケットはすべて最適経路を通過した．構成 1 の場合のパケットフローも同様のシーケンスとなる．制 御パケット自体が Dummynet を経由するため，最適化処 理には構成 2 より多くの時間が必要である．しかし， 1 回 目の通信パケットが Dummynet を 2 回通過するため，制 御パケットと通信パケットの相対的な時間関係は変わらな い．このため，同様に以後のパケットは全て最適経路で送 受信される．このように，構成 1 ， 2 とも自律的経路最適 化に起因する性能劣化はほとんどないことが想定できる．
4.3
スループット測定自律的経路最適化の利点としては， (1) 高スループット が得られること， (2) パケット伝送遅延が減少すること，
(3)RS の負荷が軽減されること， (4) ネットワーク負荷が 軽減されることがあげられる．この中で，本論文では (1) 高スループットに着目し評価を行った．
高スループットが特に要求される場面は，大容量ファイ
NAT
MNDC
MNDC
CNRS SW
NAT
研究室ネットワーク
CN MN
Primary DNS
Dummynet
NAT
MCDC
MNDC
CNRS SW
NAT
研究室ネットワーク
CN MN
Primary DNS
Dummynet
NAT
CN(a) 構成1 (b) 構成2
図
6
試験ネットワーク構成Fig. 6 Network configuration of the trial system.
ルの転送時である．ファイル転送時には， TCP が利用され るが，ネットワークが持つキャパシティを最大限活かすよ うに，通信端末側でウインドウサイズを調整する輻輳制御 が実行される．輻輳制御の働きは，ネットワーク状態（伝 送遅延とパケットロス率）により大きく変動する．
そこで，提案方式のスループットを評価する方法として，
図 6 に示した試験ネットワーク構成において， NTMobile
や経路最適化を一切考慮せずに，ネットワークが持つキャ
RS NAT
MCAutonomous Tunnel Request Autonomous Tunnel Response
SYNSYN ACK
FTP Data
Optimized point . Capsulated Packet
MN CN
Tunnel establishment via RS
26.30ms
ACK
1.65ms
1.36ms 0.20ms 0.71ms 0.01ms 18.25ms 0.16ms
3.96ms Tunnel Request
Tunnel Request Tunnel Response
Tunnel Response
SYN
図
7
自律的経路最適化の動作Fig. 7 Behavior of the autonomous route optimization.
パシティを最大限に活かしたときのスループットを目標値 として設定した．ここではこの目標値を素スループットと 呼び，提案方式が素スループットにどこまで近づけるかに より，ネットワークのキャパシティを有効に活用できてい るかどうかの指標とした．
構成 1 （異なる NAT 配下間の通信）では，素スループッ トを測定するために， NAT MN と NAT CN に静的 NAT テー ブルを設定した．これにより MN と CN が RS を経由しな くとも通信が可能な状態を作り，素スループットを求めた．
ここで Dummynet の設定値（伝送遅延 10m 秒，パケット ロス率 0.05% ）は，国内のサイトをアクセスしたときの実 測値から決定したもので，インターネットを模擬している．
また，構成 2 （同一 NAT 配下の通信）では， NAT MC 配下 の LAN 内直接通信の値を素スループットとした．このと き， NAT MC はスイッチと同様の動作となる．
表
2 に各装置の仕様を示す．物理的接続は 1000BASE-T による有線 LAN とし， netperf *2 を用いた TCP のスルー プット測定を実施した．測定は 60 秒間の TCP スループッ ト測定を MN から CN に 10 回行い，その平均値を取得し た． Netperf の設定値はデフォルト値 *3 を用いた．なお，
制御メッセージ及びアプリケーションパケットの暗号化 及び認証アルゴリズムは AEC-CBC ， HMAC-MD5 とし，
DC-NTM 端末間で用いられる共通鍵（鍵長 128bit ）を事 前にそれぞれ MN と DC MN 間， CN と DC CN 間， DC MN と DC CN 間に設定した．上記測定環境において，素スルー プット測定結果は，構成 1 では 16.61Mbps ，構成 2 では 935.61Mbps となり，この値を目標値として設定した．
表
3 は，構成 1 ， 2 において，オリジナル NTMobile と提 案方式のスループット測定結果を示したものである．ボト ルネックが何に起因しているかを明らかにするため，提案方
*2 http://www.netperf.org/
*3 RecvSockSize:87380 Byte, SendSockSize:16384 Byte, SendMessageSize:16384 Byte
表
2
試験装置の仕様Table 2 Specification of test devices.
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 NTM node Ubuntu 10.04 Core 2 Duo U9400(1.4GHz) 1.8GB
表
3
スループット測定結果（Mbps
）Table 3 Results of throughput measurements(Mbps).
構成
1
構成2
素スループット16.61
935.61
オリジナルNTMobile 8.99
8.70
提案方式（暗号化処理あり）20.17
255.62
提案方式（暗号化処理なし）20.79
898.69
式では NTMobile の暗号化処理を外した場合の測定も行っ た．表 3 の結果からわかるように，オリジナル NTMobile では，構成 1 ，構成 2 とも RS を経由した通信となるため，
ネットワークのキャパシティを十分活かすことができてい ないことがわかる．提案方式により，エンドエンド通信が 実現され，スループットが改善されている．提案方式（暗 号化処理あり）構成 2 では，オリジナル NTMobile より大 幅にスループットが向上したが，素スループットと比べる と同等の性能が達成できていない．しかし，提案方式（暗 号化処理なし）構成 2 では素スループットに近い結果が得 られている．このことから，提案方式（暗号化処理あり）
構成 2 のボトルネックは通信端末の暗号化処理であったこ とがわかる．提案方式（暗号化処理あり）構成 2 において も素スループットに近づけるためには，暗号化処理のハー ドウエア化などが必要になると考えられる．
次に，提案方式構成 1 では暗号化処理の有無にかかわら ず，素スループットを上回るという結果が得られた．提案 方式と素スループットの測定環境の大きな違いは，通信 パケットが UDP カプセル化されているか否かである．一 方， NAT には SPI 処理が標準で組み込まれており， TCP パケットに対してはシーケンス番号整合性チェックが行わ れる．素スループット環境では， Dummynet でのパケット ロスがシーケンス番号チェックに影響を与えている可能性 がある．提案方式では， NAT が UDP 処理となるためこの 影響を一切受けず，カプセル化されているにもかかわらず スループットが向上したと考えられる．なお，本件につい ては今後より詳細な検証を行う必要がある．
表 3 におけるスループットの処理ネックを整理すると
以下のとおりである．個別の性能測定結果により， RS の
中継性能は約 27Mbps ， NAT の中継性能は約 150Mbps で
あった．このことから， NAT や RS などの通信機器には
十分な余裕があり，ボトルネックにはならない．素スルー
プット構成 2 ，提案方式（暗号化処理なし）構成 2 は，伝送
速度 1000Mbps に近い値を達成していることから，ボトル
ネックは LAN の伝送速度であると言える．素スループッ
ト構成 2 に対して提案方式（暗号化処理なし）構成 2 のス ループットが低い理由は，後者ではパケットがカプセル化 されているため，パケット長に対するデータ比率が落ちる ためである．提案方式（暗号化処理あり）構成 2 の処理ボ トルネックは，上記で述べたように通信端末の暗号化処理 である．素スループット構成 1 ，オリジナル NTMobile 構 成 1 ，オリジナル NTMobile 構成 2 ，提案方式（暗号化処 理あり）構成 1 ，および提案方式（暗号化処理なし）構成 1 のボトルネックは，伝送遅延（ 10m 秒）とパケットロス率
（ 0.05% ）により TCP の輻輳ウインドウサイズが調整され ることが原因で，ボトルネックはネットワークである．オ リジナル NTMobile では構成 1 ，構成 2 ともにダミーネッ トを 2 回通過するため，ネットワークのボトルネックが重 畳して性能が低下することがわかる．以上のように，提案 方式はオリジナル NTMobile と比較して，ボトルネックが 緩和されてスループットが向上するため，有用な方式であ るということができる．
4.4 NTMobile
のハンドオーバ自律的経路最適化は， MN がネットワークを切り替えた 時にも，ハンドオーバ終了後に実行される．そこで，ハン ドオーバ時の通信断絶時間に係る評価を以下に示す．
NTMobile のハンドオーバ時間に関しては文献 [19] にて 報告されている．この結果によると，ハンドオーバ時に発 生する通信断絶時間は平均 0.99 秒であった．その内訳は，
アクセスポイントの切り替えおよび DHCP による IP アド レスの取得に 0.95 秒， NTMobile によるトンネル再構築 処理に 0.04 秒であり， NTMobile 以外の処理が大半を占 めることがわかった．ハンドオーバ時間を短縮するには，
DHCP 処理の高速化 [24], [25] や，異なる無線システムを 用いたシームレスハンドオーバ技術 [26] などが有用であ り， NTMobile とは独立してこれらの技術を併用すること が有用と考えられる．また， NTMobile の中で考えられる 解決手法として，複数の無線インタフェース（ 3G と WiFi など）を使用し，ハンドオーバ前にネゴシエーションを完 了しておくことにより，シームレスハンドオーバを実現す ることも可能である [20] ．この方法によると，ハンドオー バ時に発生するパケットロスをなくすことも可能である．
5. まとめ
本論文では，通信を行う両 NTM 端末が NAT 配下に存 在する場合に RS を経由しない最適経路を自律的に生成す る方式について提案を行った．提案方式では，両 NTM 端 末が互いにパケットを送信し合うことによりパケット到 達性を調べ，パケット到達性がある場合には RS を経由し ない最適な通信経路を構築できることを示した．本提案で は，必ず中継通信経路を構築してから経路の最適化を行う ため，経路の最適化ができない場合においても通信を継続
可能である．提案方式のプロトタイプシステムにおいて，
自律的経路最適化を実際に動作させ，最適化後にスルー プットが向上することを確認した．
付 録
以下に NTMobile に係る文献番号とその概要を示す．
[16]: オリジナル NTMobile により，通信接続性を保証で きる点に着目して，その考え方と原理を説明した文献 . 実 装に係る評価として，通信開始時のオーバヘッドを掲載．
[17] ：オリジナル NTMobile により，移動透過性を実現 できる点に着目して，その考え方と原理を説明した文献．
実装に係る評価として，通信スループットを掲載．
[18] ： NTMobile を IPv6 に適用する方法についての検討 とその実装結果の報告 .
[19] ： NTMobile を Android に移植しハンドオーバ時の 通信断絶時間とスループットの評価結果を報告．
[20] ： NTMobile に複数インタフェースを適用してパケッ トロスレスハンドオーバを実現する方式の検討．
[21] ： RS の実装と動作検証を行い，性能測定した結果の 報告 .
[22] ： IPv4/IPv6 混在環境における NTMobile の実現方 法とその実装．
参考文献
[1] Rosenberg, J., Mahy, R., Matthews, P. and Wing, D.:
Session Traversal Utilities for NAT (STUN), RFC 5389, IETF (2008).
[2] BryanFord, P.S. and Kegel, D.: Peer-to-Peer Communi- cation Across Network Address Translators (2005).
[3] Mahy, R., Matthews, P. and Rosenberg, J.: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN), RFC 5766, IETF (2010).
[4] Rosenberg, J.: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols, RFC 5245, IETF (2010).
[5] Westerlund, M. and Perkins, C.: IANA Registry for Interactive Connectivity Establishment (ICE) Options, RFC 6336, IETF (2011).
[6]
鈴木秀和，宇佐見庄五，渡邊 晃：外部動的マッピングに よりNAT
越え通信を実現するNAT-f
の提案と実装，情 報処理学会論文誌，Vol.48, No.12, pp.3949.3961 (2007).
[7] Perkins, C., Johnson, D. and Arkko, J.: Mobility Sup- port in IPv6, RFC 6275, IETF (2011).
[8] Ishiyama, M., Kunishi, M., Uehara, K., Esaki, H., and Teraoka, F.:LINA : A New Approach to Mobiity Sup- port in Wide Area Networks, IEICE Trans. Commun.
Vol.E84-B, pp.2076-2086 (2001).
[9]
相原玲二，藤田貫大，前田香織，野村嘉洋：アドレス変換 方式による移動透過インターネットアーキテクチャ，情 報処理学会論文誌，Vol.43, pp.3889.3897 (2002).
[10] Perkins, C.,:IP Mobility Support for IPv4, Revised, RFC5944, IETF (2010).
[11]
関 顕生，岩田裕貴，森廣勇人，前田香織，近堂徹，岸場 清悟，西村浩二，相原玲二：IPv4
拡張した移動透過通信アーキテクチャ
MAT
の設計と性能評価，情報処理学会 論文誌，Vol.52, No.3, pp.1323.1333 (2011).
[12]
竹内元規，鈴木秀和，渡邊 晃：エンドエンドで移動透過 性を実現するMobile PPC
の提案と実装，情報処理学会 論文誌，Vol.47, No.12, pp.3244-3257 (2006).
[13] Montenegro, G.,Reverse Tunneling for Mobile IP, re- vised, RFC3024, IETF(2001).
[14] Levkowetz, H., and Vaarala, S.,:Mobile IP Traversal of Network Address Translation (NAT) Devices, RFC3519, IETF(2003).
[15]
鈴木秀和，渡邊 晃：プライベートネットワーク内のノー ドを通信相手とした移動透過性の実現方式，電子情報通 信学会論文誌. B
，Vol.J92-B, No.1,pp.109.121 (2009).
[16]
鈴木秀和，上醉尾一真，西尾拓也，水谷智大，内藤克浩，渡邊晃：
NTMobile
における通信接続性の確立手法と実装，情報処理学会論文誌，
Vol.54
，No.1
，Jan. 2012
．掲 載決定[17]
内藤克浩，上醉尾一真，西尾拓也，水谷智大，鈴木秀和，渡邊晃，森香津夫，小林英雄：
NTMobile
における移動透 過性の実現と実装，情報処理学会論文誌，Vol.54
，No.1
，Jan. 2012
．掲載決定[18]
上醉尾一真，鈴木秀和，内藤克浩，渡邊 晃：IPv6
ネッ トワークにおけるNTMobile
の検討，情報処理学会研究 報告，Vol.2011-MBL-59, No.9, pp.1-7 (2011).
[19]
上醉尾一真，鈴木秀和，内藤克浩，渡邊 晃：NTMobile
の
Android
端末への実装と評価，情報処理学会研究報告，Vol.2012-MBL-62, No.19, pp.1-8 (2012).
[20]
福山陽祐，鈴木秀和，渡邊 晃：IPv4
移動体通信において 携帯電話網と無線LAN
間をシームレスに移動する方式 の提案，DICOMO2011
論文集，pp.1115-1120 (2011).
[21]
土井敏樹，鈴木秀和，内藤克浩，渡邊 晃：NTMobile
に おけるRS
の検討，DICOMO2012
論文集，pp.1162-1168 (2012).
[22]
上醉尾一真，鈴木秀和，内藤克浩，渡邊晃：IPv4/IPv6
混 在環境で移動透過性を実現するNTMobile
の実装と評価，マルチメディア
