課題研究 エンタープライズネットワークおよびプロバイダ ネットワーク

NAIST-IS-MR1251106
課題研究
エンタープライズネットワークおよびプロバイダ
ネットワークにおける IPv4 Sunset 手法に関する調査
村田 大輔
2014 年 6 月 18 日
奈良先端科学技術大学院大学
情報科学研究科 情報科学専攻
本報告書は奈良先端科学技術大学院大学情報科学研究科に
修士 (工学) 授与の要件として提出した課題研究の報告書である。
村田 大輔
審査委員：
藤川 和利 教授
（主指導教員）
山口 英 教授
（副指導教員）
猪俣 敦夫 准教授
（副指導教員）
エンタープライズネットワークおよびプロバイダ
ネットワークにおける IPv4 Sunset 手法に関する調査∗
村田 大輔
内容梗概
インターネットの急速な成長に伴い，IPv4 アドレス空間の枯渇が現実のものと
なっている。この問題を解決するために，従来の Internet Protocol である IPv4 に
代わり新しく IPv6 が提案された。ユーザが利用するコンピュータなどの端末は，
ここ数年で発売されているものに関しては IPv6 に対応している。一方で，IPv6
の普及は本格化しているとは言い難い状況にある。そのため，IPv4 から IPv6 へ
の円滑な移行に問題が生じている。そこで，IPv4 から IPv6 への移行を補助する
技術として IPv4/IPv6 移行・共存に関する技術が多く提案されるようになった。
現実問題として，即座に IPv4 を捨て IPv6 を利用することはできないため，IPv6
過渡期としてこれらの移行・共存技術を利用する時期を設ける必要がある。本課
題研究では，この過渡期の中で，如何にして IPv6 の利用を促進し，また，限ら
れた IPv4 の使用量を削減するかについて一考する。
キーワード
IPv6, IPv4 Sunset, IPv6 移行, エンタープライズネットワーク, キャンパスネット
ワーク
∗
奈良先端科学技術大学院大学 情報科学研究科 情報科学専攻 課題研究, NAIST-IS-MR1251106,
2014 年 6 月 18 日.
i
A study of IPv4 Sunset technique in enterprise
network and provider network∗
Daisuke Murata
Abstract
As the Internet grows rapidly, the exhaustion of the IPv4 addresses space became a real problem. IPv6 was proposed to resolve this problem. Terminal what
has been launched in the last few years, such as a computer used by many people
has capability to connect with IPv6. However, deployment of IPv6 is not well,
gap occurs in a smooth transition from IPv4 to IPv6. So, IPv4/IPv6 transition
coexistence technology to support a smooth transition from IPv4 to IPv6 has
come to be proposed. Realistically, it is not possible to use the IPv6 when IPv4
discarded immediately. It is necessary to provide the IPv6 transition period to
take advantage of the migration, coexistence of these technologies. In this paper,
we thought about what to reduce the use of IPv4 in this transition period.
Keywords:
IPv6, IPv4 Sunset, IPv6 Migration, Enterprise network, Campus network
∗
Master’s Report, Department of Information Science, Graduate School of Information
Science, Nara Institute of Science and Technology, NAIST-IS-MR1251106, June 18, 2014.
ii
目次
1. はじめに
1
1.1
研究背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
研究の目的
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
本論文の構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2. IPv6 への移行
6
2.1
IPv4 アドレス枯渇問題と IPv6 プロトコルへの移行 . . . . . . . .
6
2.2
IPv4 と IPv6 の比較 . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3
IPv6 への移行前に考えるべき事 . . . . . . . . . . . . . . . . . . .
15
2.3.1
コアネットワーク . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.2
サーバ側ネットワーク . . . . . . . . . . . . . . . . . . . .
17
2.3.3
クライアント側ネットワーク . . . . . . . . . . . . . . . .
17
IPv6 移行に向けた課題 . . . . . . . . . . . . . . . . . . . . . . . .
18
2.4.1
グローバルアドレスを利用した通信 . . . . . . . . . . . . .
18
2.4.2
アドレス量の増加 . . . . . . . . . . . . . . . . . . . . . . .
18
2.4.3
マルチキャストを多用した通信 . . . . . . . . . . . . . . .
19
2.4.4
IPv4 と仕様が異なる点での注意 . . . . . . . . . . . . . . .
20
IPv6 移行に必要な要件 . . . . . . . . . . . . . . . . . . . . . . . .
22
2.4
2.5
3. IPv6 移行関連技術
27
3.1
IPv6 移行関連技術の棲み分け . . . . . . . . . . . . . . . . . . . .
27
3.2
主要な IPv4/IPv6 移行共存技術 . . . . . . . . . . . . . . . . . . .
32
3.2.1
NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.2.2
464XLAT (464NAT) . . . . . . . . . . . . . . . . . . . . .
35
3.2.3
MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.4
DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.5
MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2.6
SA64T . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
iii
3.3
3.4
IPv4/IPv6 移行技術の現状 . . . . . . . . . . . . . . . . . . . . . .
42
3.3.1
IPv4/IPv6 移行技術の比較 . . . . . . . . . . . . . . . . . .
42
3.3.2
IPv4/IPv6 移行技術の乱立 . . . . . . . . . . . . . . . . . .
44
IPv4/IPv6 移行技術に共通する問題 . . . . . . . . . . . . . . . . .
44
3.4.1
MTU 問題 . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.4.2
NAPT 問題 . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4. IPv6 移行関連技術によるネットワーク運用
48
4.1
ブロードバンドネットワークの内訳 . . . . . . . . . . . . . . . . .
48
4.2
IPv6 移行関連技術を用いたサービス . . . . . . . . . . . . . . . .
51
4.2.1
Android CLAT . . . . . . . . . . . . . . . . . . . . . . . .
51
4.2.2
T-Mobile USA
. . . . . . . . . . . . . . . . . . . . . . . .
52
4.2.3
China Mobile . . . . . . . . . . . . . . . . . . . . . . . . .
52
IPv6 移行関連技術の運用により得られた知見 . . . . . . . . . . .
53
4.3.1
T-Mobile USA での知見 . . . . . . . . . . . . . . . . . . .
54
4.3.2
Arkko らによる知見 . . . . . . . . . . . . . . . . . . . . . .
55
4.3.3
櫨山らによる知見 . . . . . . . . . . . . . . . . . . . . . . .
57
4.3.4
Cisco における知見 . . . . . . . . . . . . . . . . . . . . . .
63
4.3.5
JANOG31 会場ネットワークにおける知見 . . . . . . . . .
63
4.3.6
Interop Tokyo 2013 ShowNet における知見 . . . . . . . . .
64
4.3.7
本学クライアントネットワークにおける知見 . . . . . . . .
69
4.3
5. IPv4 Sunset に向けて
72
5.1
モバイルオペレータの場合 . . . . . . . . . . . . . . . . . . . . . .
72
5.2
キャンパスネットワークの場合 . . . . . . . . . . . . . . . . . . .
73
国立高専の事例 . . . . . . . . . . . . . . . . . . . . . . . .
74
グローバル IPv4 アドレスをベースとした構成 . . . . . . . . . . .
75
5.3.1
NAIST における一例 . . . . . . . . . . . . . . . . . . . . .
76
5.3.2
NAIST における IPv4 通信の内訳 . . . . . . . . . . . . . .
76
5.2.1
5.3
iv
5.4
プライベート IPv4 アドレスをベースとしたエンタープライズネッ
トワークの場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6. 考察
80
7. おわりに
82
謝辞
84
参考文献
86
v
図目次
1
IPv4 アドレスのプール状況 . . . . . . . . . . . . . . . . . . . . .
2
2
FireEye 社製品での検知結果 . . . . . . . . . . . . . . . . . . . . .
3
3
FortiGate 社製品での検知結果 . . . . . . . . . . . . . . . . . . . .
4
4
IPv4 経路数の推移 . . . . . . . . . . . . . . . . . . . . . . . . . .
8
5
RIR 間での IP アドレスの移転 . . . . . . . . . . . . . . . . . . . .
9
6
IPv6 ネットワークの広がり . . . . . . . . . . . . . . . . . . . . .
10
7
World IPv6 Day からの伸び . . . . . . . . . . . . . . . . . . . . .
11
8
IPv6 アドレスフォーマット . . . . . . . . . . . . . . . . . . . . .
13
9
クライアント―サーバ間のネットワークモデル . . . . . . . . . . .
16
10
RA がネットワークセグメントを超える構成 . . . . . . . . . . . .
20
11
IP 構成の推移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
12
接続方式における閲覧結果の違い . . . . . . . . . . . . . . . . . .
24
13
IPv6 ベースネットワークのイメージ . . . . . . . . . . . . . . . .
25
14
移行技術の推移 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
15
NAT センター集約型 . . . . . . . . . . . . . . . . . . . . . . . . .
29
16
NAT 分配型 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
17
トランスレーション・カプセル化の模式図 . . . . . . . . . . . . .
30
18
ステートレス・ステートフルの模式図
. . . . . . . . . . . . . . .
32
19
NAT64/DNS64 の模式図 . . . . . . . . . . . . . . . . . . . . . . .
33
20
NAT64 におけるアドレス変換 . . . . . . . . . . . . . . . . . . . .
33
21
NAT64/DNS64 の変換の仕組み . . . . . . . . . . . . . . . . . . .
34
22
464XLAT の模式図 . . . . . . . . . . . . . . . . . . . . . . . . . .
35
23
MAP における FMR . . . . . . . . . . . . . . . . . . . . . . . . .
36
24
MAP における port mapping algorithm . . . . . . . . . . . . . . .
37
25
MAP における IPv4 アドレスの配り方 . . . . . . . . . . . . . . .
38
26
MAP-T の模式図 . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
27
DS-lite の模式図 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
28
DS-Lite のフロー . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
vi
29
MAP-E の模式図 . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
30
SA46T の模式図 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
31
SA46T の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
32
SA46T アドレス構造 . . . . . . . . . . . . . . . . . . . . . . . . .
43
33
メッシュ型ネットワーク . . . . . . . . . . . . . . . . . . . . . . .
45
34
ハブ＆スポーク型ネットワーク . . . . . . . . . . . . . . . . . . .
46
35
規格の整理
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
36
MTU 問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
37
ポート別のブロードバンドトラフィック（概要） . . . . . . . . . .
49
38
Android CLAT の流れ . . . . . . . . . . . . . . . . . . . . . . . .
52
39
Android CLAT による IPv6 セルラーネットワーク . . . . . . . . .
53
40
China Mobile におけるモバイル用 IPv6 トライアルネットワーク .
54
41
Cisco におけるネットワーク構成
. . . . . . . . . . . . . . . . . .
63
42
JANOG31 におけるネットワーク構成 . . . . . . . . . . . . . . . .
64
43
iOS 7 におけるユーザインターフェース . . . . . . . . . . . . . . .
70
44
Android 4.2.x (Jelly Bean) におけるユーザインターフェース . . .
71
45
曼陀羅ネットワーク概略図 . . . . . . . . . . . . . . . . . . . . . .
77
表目次
1
IPv4 のクラスによるアドレス数の違い . . . . . . . . . . . . . . .
7
2
IPv4 と IPv6 の違い . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3
DHCPv6 の標準化と実装時期 . . . . . . . . . . . . . . . . . . . .
15
4
フィルタリングすべきでない ICMPv6 . . . . . . . . . . . . . . . .
21
5
アドレス自動設定機構における設定可能項目の差異 . . . . . . . .
21
6
各セグメントのサービスプロバイダの考慮事項 . . . . . . . . . . .
26
7
IPv4/IPv6 移行・共存技術 . . . . . . . . . . . . . . . . . . . . . .
27
8
IPv4/IPv6 移行・共存技術の比較 . . . . . . . . . . . . . . . . . .
44
9
ポート別のブロードバンドトラフィック（詳細） . . . . . . . . . .
50
vii
10
主要サービスの IPv6 対応状況 . . . . . . . . . . . . . . . . . . . .
11
IPv6 only Network におけるインスタントメッセンジャーの動作状況 56
12
IPv6 only Network におけるゲームの動作状況 . . . . . . . . . . .
57
13
WIDE Camp における IPv6 実験状況 . . . . . . . . . . . . . . . .
58
14
OS による IPv6 アドレス自動設定機構の稼働状況 . . . . . . . . .
59
15
モバイル端末での IPv6 周辺の UI 対応状況 . . . . . . . . . . . . .
60
16
JANOG31 にて使用した機器 . . . . . . . . . . . . . . . . . . . . .
65
17
Interop Tokyo 2013 ShowNet にて使用した機器 . . . . . . . . . .
65
18
Interop Tokyo 2013 ShowNet にて使用した MAP-E パラメータ . .
66
19
国立高専が保有している歴史的 PI アドレスのアドレスブロック数
75
20
本学でのアドレスブロックの利用状況
. . . . . . . . . . . . . . .
76
21
本学における平日 1 日のデータ . . . . . . . . . . . . . . . . . . .
78
viii
55
1. はじめに
1.1 研究背景
今日においてインターネットは重要な社会基盤となっている。現在，インター
ネットでは主に Internet Protocol version 4 (IPv4) というプロトコルを通信に用
いている。この IPv4 は 1981 年に仕様が公開され，以来，現在に至るまで約 30
年以上も利用され続けている。インターネットではコンピュータ間で通信を行う
際にお互いを識別するため，IPv4 プロトコルに則った IPv4 アドレスを利用して
いる。IPv4 アドレスとはネットワークに接続されたコンピュータ 1 台 1 台に割り
振られた識別番号であり，インターネット上ではこの数値に重複があってはなら
ないため，割り当てなどの管理は各国の Network Information Center (NIC) が
行っている。そのような中，IPv4 アドレスの枯渇が問題視され，事実，2011 年
2 月 3 日に Internet Assigned Numbers Authority (IANA) が管理する IPv4 アド
レスプールが枯渇，同年 4 月 15 日には Asia-Pacific Network Information Centre
(APNIC) の IPv4 アドレス枯渇し，翌年 9 月 14 日には Réseaux IP Européens
Network Coordination Centre (RIPE NCC) においても IPv4 アドレス最後の 1 ブ
ロックの割り当てが始まった [1, 2]。図 1 で示されるように IPv4 アドレス在庫枯
渇が現実となったことで，事業者では IPv4 アドレス移転手続きを通じたアドレ
スの売買も行われるようになった [3, 4]。
一方で，現在，IPv4 アドレス割り当てが厳しくなったことから，将来へ向けた
Internet Protocol version 6 (IPv6) 導入の準備が本格化している。この IPv6 は，
IPv4 の枯渇を問題視し，それに変わる新たなプロトコルとして 1998 年 12 月に登
場したものである [5]。近年では IPv6 によるサービスは増加しており，Internet
Society (ISOC) が 2014 年 6 月 6 日の 1 日限定で IPv4 サービスを試験的に停止す
る旨を発表している [6]。
さらに，日本においては，JPNIC からの歴史的 Provider Independent (PI) ア
ドレスへの課金が 2012 年度から始まっており [7]，膨大な数の歴史的 PI アドレス
を保有する大学などにも大きな負担となっている。そこで，早期に IPv4 の使用
量を削減し，IPv6 への移行を行うことが望まれる。最近の動向としては，IPv4
1
図 1 IPv4 アドレスのプール状況
Sunset と呼ばれるキーワードで IPv4 をなくすための議論も行われている [8, 9]。
IPv6 は IPv4 と比べ，広大なアドレス空間を持つがゆえに，現行の IPv4 と互
換性は無い。そのため，従来では，IPv6 の導入と言えば，IPv4 と IPv6 を同時に
運用するデュアルスタック・パラレルスタックモデルが IPv6 導入の基本とされ
てきた。しかし，デュアルスタック・パラレルスタックモデルでは単純に考えて
運用に 2 倍の労力を必要とすること，更に，バックボーン側の IPv6 化が進んで
おり，今後 IPv6 が主流と成り行くことを考えると，IPv4 と IPv6 の環境を両方同
時に構築することは，多くの苦労を要する。
そこで，本論文では，エンタープライズネットワークおよびプロバイダネット
ワーク全体に IPv6 を展開してゆくことを考慮する。しかしながら，IPv6 だけで
は IPv4 との接続性が失われるため，IPv4/IPv6 移行技術を介する形で通信を行
うモデルを考えることとする。現状，IPv4 のみを対象としているサービスも多く
2
存在しており，IPv6 が普及しても，当面は IPv4 と IPv6 が混在し，完全な IPv6
一本化を行うことは難しい。特に，エンドユーザ向けのサービスの多くは IPv4
のみで展開されており，単純に IPv6 への一本化を行うと，実用に耐えない環境
となることが想定される。また，IPv6 のみでは使えないサービスには適宜，IPv4
を配布し運用する方針とし，IPv4 アドレスの利用を最低限にとどめる。
1.2 研究の目的
近年，IPv4 アドレス枯渇が現実のものとなり，Carrier Grade NAT (CGN) [10]
を用いた IPv4 の利用削減 [11, 12] や IPv6 の利用促進 [13] が進んでいる。ただし，
既存のユーザは IPv4 でこれまで通り満足にインターネットを利用することがで
きるため，多くのユーザにとって関心が薄いことも事実である。
Trojan
Bot
Backdoor
Trojan.M0zilla (Singapore)
Trojan.Zbot (US)
4.6%
9.1%
24.7%
70.7%
90.9%
(a) 会期 3 日間における攻撃
(b) 会期 3 日間における攻撃（出展者以外）
図 2 FireEye 社製品での検知結果
昨年の Interop Tokyo 2013[14] において，World IPv6 Day および World IPv6
Launch を経た年のネットワークでは，IPv6 化が進んでおり，IPv6 によるセキュ
リティは会場内ネットワークである ShowNet を構成しているセキュリティ機器の
Syslog を ShowNet の構築段階 (Hot Stage) からサーバへ転送し，Hot Stage から
3
SSH
Web
ping
telnet
2.5%
2.5%
2.5%1.3%
3.8% 1.3%
3.8% 1.3%
6.3%
2.5%
11.3%
23.8%
40.0%
12.5%
62.5%
22.5%
(a) 不正アクセス（プロトコル別）
China
US
Bangladesh
Serbia
Japan
Spain
Germany
India
Thailand
Poland
Belgium
Russia Federation
(b) 不正アクセス（国別）
図 3 FortiGate 社製品での検知結果
会期終了までの Syslog 解析を行った。中でも，Interop がイベントとして一般公
開されている会期 3 日間に絞ったデータを以下に示す。
FireEye 社の Malware Protection System から得られた警告ログをまとめたも
のを図 2(a) に示す。なお，警告ログの総計は 1867 件であった。また，当該ログ
から送信元 IP アドレスが出展者割り当て IP となっているものを省いた結果を図
2(b) に示す。なお，こちらの総計は 11 件と非常に少ないものであった。
次に FortiGate 社の Unified Threat Management (UTM) から得られた警告ロ
グをまとめたものの中から，プロトコルの種類別となっているものを図 3(a) に，
国別となっているものを図 3(b) に示す。なお，警告ログの総計は 80 件であった。
また，これらの攻撃は全て IPv4 からのアクセスであり，IPv6 からの攻撃は観
測できなかった。今回の ShowNet では，IPv4 アドレスに関しては部分的に情報
公開していたのに対し，IPv6 アドレスに関しては公開されていなかったことを考
慮しても，IPv6 による不正なトラフィックは少なかったと言わざるを得ない。
本来ならば，不正な振る舞いが少ないことは喜ぶべきことであるが，Interop と
いうアドレスプレフィックスが広く知られているネットワークに，IPv6 での攻撃
が来なかったということは，それだけ末端にまで IPv6 が広がっていないという
ことの証とも言える。
4
本研究では，IPv6 の導入と共に，利用可能枠が少なくなり，維持コストの必
要となった IPv4 を如何にして削減してゆくかについて一考することを目的とす
る。その上で，従来の IPv4 ネットワークとの協調性を保ちつつ，来るべき IPv6
ネットワークに対してのエンタープライズネットワークの対応を図るための一考
を行う。
1.3 本論文の構成
本論文の構成は次の通りである。まず，2 章において IPv6 の概略および移行
に向けた課題について述べた後，3 章で IPv4/IPv6 移行関連技術について説明す
る。4 章においては今日のブロードバンドネットワークにおけるトラフィックの
特徴と，現時点での 3 章で述べた IPv4/IPv6 移行関連技術の活用事例および，そ
の知見について述べる。5 章では，プロバイダやエンタープライズ，キャンパス
ネットワークについて各事例と共に説明し，その中で人間が直接使用することの
ないコアネットワークにおける IPv4 Sunset 手法について一考する。6 章にてそ
れらの考察を行った後，最後に 7 章で本論文のまとめを述べる。
5
2. IPv6 への移行
2.1 IPv4 アドレス枯渇問題と IPv6 プロトコルへの移行
近年，IPv4 アドレスの枯渇が現実の問題となっている。新規に IPv4 アドレス
を割り振ることができなくなると，新規サービス事業者の参入や個人ユーザのイ
ンターネットへの新規加入が難しくなる。結果として，インターネットの普及や
拡大を阻害してしまうこととなる。
現時点でのこの問題の解決策は，大きく分けて以下の 3 つである。
• IPv4 アドレスの効率的な利用
• IPv4 アドレスの移転・売買
• IPv6 の導入
IPv4 アドレスの効率的な利用
1 つ目の IPv4 アドレスの効率的な利用は昔から行われてきた。冒頭で述べた通
り，IPv4 というプロトコルが仕様として確立したのは 1980 年初頭である。そこ
から 10 年近く経った 1990 年代初頭に，早くも IPv4 の問題点として，IP アドレ
スの枯渇が指摘されていた。当時のアドレス割り当ての方式によると，IPv4 アド
レスは 1995 年にはなくなってしまうと言われていた [15]。
これは当時のアドレッシング体系に由来しており，IPv4 アドレスにはクラスと
いう概念が存在し，このクラスに基づいて IPv4 アドレス割り当てがなされてい
た。これは，32bit の IP アドレスをネットワークアドレス部とホストアドレス部
に分割する仕組みで，クラスは A, B, C の 3 種類に分けられる1 。分割はそれぞ
れ IPv4 アドレスの上位 8 ビット，16 ビット，24 ビットを分割したものがそれぞ
れクラス A, B, C となり，上位のクラスほど使えるホストアドレスが多い。使用
できるアドレス数を表 1 に示す。
1
この他にクラス D, E が存在するが，技術的な観点および，将来の使用のために予約されてい
る。
6
表 1 IPv4 のクラスによるアドレス数の違い
クラス
最大ネットワーク数
最大ホスト数
A
128
1,677,214
B
16,384
65,534
C
2,097,152
254
かつて，IP アドレスの枯渇という概念が無かった時代には，アドレスの配布は
クラス単位で行われており，組織の規模に応じた柔軟な IP アドレスの配分は行
われておらず，組織が申請したクラスがそのまま割り振られるということが多々
あった。これにより，実際はそこまで多くの IP アドレスを必要としないのにク
ラス A やクラス B を保持する組織が多く存在した。
その結果，インターネットが広く普及した現在，多くの組織がアドレスの配布
を申請をしても配布するべきアドレスブロックが無く，新規配布が困難になると
いう事態が発生した。これが，IPv4 アドレスの枯渇を意識し出した始まりと言え
る。この時，すでに配布しているアドレスを返却した上で再度クラス単位で配布す
るのではなく，旧来のクラス A, B, C といった概念を取り払い，可変長ネットマス
クを用いて，小さなブロックごとにアドレスを割り当てる Classless Inter-Domain
Routing (CIDR) [16] という方式が提案され，必要規模に応じてグローバル IPv4
アドレスを提供することにより，グローバル IPv4 アドレスの浪費を防ぐことと
なった。
しかし，そのようなアドレス配布を行ったために，同じ組織内であるのにもか
かわらず違うアドレス範囲を使用するなどの問題が発生し，組織のネットワーク
内の IP アドレスを人が意識しながら管理・運営してゆく課程で，IP アドレス管
理のトラブルを招く原因にもなり，管理者の負担が大きくなるという問題も発生
した。
更に，新規アドレスの配布は当初のクラス単位からより細かい配布をすること
が多くなった。これにより IP アドレス数の節約は可能になったが，代わりに経
路情報の増加という問題が発生した。これは，1 つの組織が複数のアドレス範囲
7
図 4 IPv4 経路数の推移
（プレフィックス）を保持しているため，経路を集約行うことができない，組織の
合併などで違うアドレス体系が一つの組織になったりすることで経路情報が複雑
雑多になってしまう，その結果として経路情報が増加した。そのため，その処理
がルータの処理能力を超えてしまう状況が発生した。
経路数の推移を図 4 に示す。図 4 に示した通り，2014 年 6 月現在では IPv4 の
経路数は 50 万経路を越えており，1988 年の計測以来，増加の一途をたどってい
る [17]。ISP 等では増え続ける経路情報に対応すべく，必要に応じて経路の間引
きやルータのリプレースなどの作業を行っている [18]。今後も後述する IPv4 アド
レスの移転・売買や，返却・再利用などを行っていくと IPv4 の経路情報はさら
に増加していくことが容易に想像できる。
さらに，分配済みの IPv4 アドレスについて、効率的な利用をさらに進めるべく，
また，LAN 内のノードには直接インターネットに接続することのできないプライ
ベート IPv4 アドレスを提供し，インターネットに接続する必要が発生した場合
8
2009年6月から移転開始
移転実績：43件
OK
ARIN会員から
APNIC会員への移転
11件
2010年2月から移転開始
移転実績：122件
日本以外の一部NIRも
移転制度実施済み
NG
NG
（現在ポリシー協議中）
（現在ポリシー協議中）
2008年12月から移転開始
移転実績：41件
図 5 RIR 間での IP アドレスの移転
のみグローバル IPv4 アドレスを利用する Network Address Translation (NAT44)
[19] の利用や，IP アドレスとポート番号の対応付けを行い，グローバル IPv4 ア
ドレス 1 つでプライベート IPv4 アドレスしか持たない複数のホストを同時にイン
ターネットへの接続性を持たせる Network Address Port Translation (NAPT44)
を利用し，アドレス数を節約することが可能となった。しかし，NAPT44 にも 1
つのグローバル IPv4 アドレスに対して確立できるセッション数が制約される問
題や，NAT を複数合わせる多段 NAT によって，アプリケーションによっては通
信に支障をきたす問題が発生することが知られている。
IPv4 アドレスの移転・売買
2 つ目の IPv4 アドレスの移転・売買は，使用していない IPv4 アドレスブロッ
クを回収して再利用したり，IPv4 アドレスブロックを売買することで IPv4 アド
レスを取得する方法である。また，図 5 に示したように，今まで事実上許可さ
9
れていなかった2 American Registry for Internet Numbers (ARIN) が管理するグ
ローバル IPv4 アドレスを，APNIC へ移転するという Regional Internet Registry
(RIR) を超えたグローバル IPv4 アドレスの移転が実現した [20, 21]。また，この
他の RIR に関しても，移転を実現できるようポリシーの策定・協議が行われて
いる。
上記 2 つの解決策は，従来から行われていたり，比較的着手が容易であるがそ
の効果は限定的であり [22]，いずれ IPv4 アドレスが不足する事に対する根本的な
解決には至っていない。
IPv6 の導入
対して，3 つ目の IPv6 の導入は，IPv4 アドレス枯渇問題に対する根本的な解
決と言える。IPv6 は 2.2 節で述べるが，IPv4 アドレスよりも大きなアドレス空
間を使用できるように設計されている。実際には 32 ビットのアドレス空間から
128 ビットのアドレス空間となり，使用可能なアドレス数は，IPv4 の約 43 億か
ら，約 340 澗（340 兆 ×1 兆 ×1 兆）に増えた。IPv6 への移行は恒久的な対応策と
言える一方で，移行にコストが掛かることと，普及が不十分であるという問題を
抱えている。2011 年 6 月 8 日に World IPv6 Day，2012 年 6 月 6 日に World IPv6
Lauch と IPv6 に関する世界的なイベントが催されており，図 6 からも読み取れ
る通り，この日を境として IPv6 の普及が進んでいる [23]。
また，図 7 に示した通り，米 Akamai 社の報告 [24] によると，World IPv6 Day
と World IPv6 Launch の 1 日間をそれぞれ比較して，Akamai 利用者の IPv6 ア
ドレスの利用数はおよそ 67 倍に増え，IPv6 からのアクセスリクエストはおよそ
460 倍に増えた。この 1 年間での普及具合は目覚ましいと言える。
2
IPv4 アドレスは，世界 5 地域（北米，欧州・中東・中央アジア，アジア・太平洋，ラテンアメ
リカ，アフリカ）を代表するそれぞれの RIR によって管理されており，これまで RIR をまたい
だ IPv4 アドレス移転は事実上許可されていなかった。2011 年に APNIC が RIR を超えた IPv4
アドレス移転についてのポリシーを承認したが，他地域で同様のポリシーが存在しなかったため，
RIR を超えた IPv4 アドレス移転は実現しなかった。
10
図 6 IPv6 ネットワークの広がり
2.2 IPv4 と IPv6 の比較
本節では，従来の IPv4 と IPv6 の違いを説明する。表 2 に IPv4 と IPv6 の比較
を示す。表 2 に示した通り，両者の根本的な違いはアドレス空間の大きさに起因
している。
まず，IPv4 と IPv6 ではアドレス体系そのものが変わっており，IPv4 では 32
ビットの 10 進値をドットで区切っていたのに対し，IPv6 では 128 ビットの 16 進
3
IPv4 においても 1 つの NIC に対して複数のアドレスを割り当てることは可能であるが，一
般的ではない。
11
(a) IPv6 の伸び率
(b) IPv6 の利用状況
図 7 World IPv6 Day からの伸び
値をコロンで区切っている。また，IPv6 では基本的に図 8 のようにホスト ID と
して 64 ビットのアドレス空間を使用する。結果として，32 ビットしかない IPv4
アドレスと 128 ビットの IPv6 アドレスが直接通信することは不可能である。
また，IPv6 にはパケットの到達範囲（スコープ）によって，リンクローカルス
コープとグローバルスコープの異なる 2 つのスコープが存在する。リンクローカ
ルスコープとは，あるリンクでのみ一意なアドレスであり，このスコープあての
パケットはルータを越えて配送されることはない。IPv4 における NAT 化されて
いないプライベートアドレスに近く，ルータ―PC 間や同一リンクの PC 間などは
こちらのアドレスを使って通信が行われることもある。グローバルスコープとは，
全 IPv6 で一意なアドレスであり，インターネット間での通信はこちらを使う。
アドレス空間以外での IPv4 と IPv6 での大きな違いは，エンドツーエンドでの
通信を実現するために基本的に NAT の導入を想定していない点や，ネットワー
クインターフェース毎に複数の IP アドレスを割り当てる点，アドレスの自動生
成に IPv4 における Dynamic Host Configuration Protocol (DHCP) [25] に相当す
12
表 2 IPv4 と IPv6 の違い
IPv4
IPv6
アドレス空間
32 ビット
128 ビット
典型的なサブネット
8 – 30 ビット
64 ビット
ドット区切り 10 進数
コロン区切り 16 進数
(e.g. 198.51.100.1)
(e.g. 2001:db8::1234:0:0:abc)
1 つのネットワークイン
1 つのネットワークイン
アドレス表記
アドレス割り当て
ターフェースに対し 1 つ
の IP アドレスを割り当て
ターフェースに対し複数の
3
IP アドレスの割り当て可能
パケットヘッダ
20 – 60 バイト
固定 40 バイト
拡張ヘッダ
なし
あり
中継ノードフラグメント
あり
なし
アドレスの自動生成
DHCP
Stateless address autoconfiguration (SLAAC), DHCPv6
る DHCPv6[26] に加え，Stateless address autoconfiguration (SLAAC) [27] によ
る生成機能がある点が挙げられる。
IPv6 でのアドレス設定は，ステートレスとステートフルの 2 種類がある。ス
テートとは，通信セッションの『状態』を意味している。それぞれ，ステートレ
スではユーザの通信について状態を管理しなくて良い設定を，ステートフルでは
ユーザの通信について状態を管理しなくてはならない状設定を指す。
ステートフルとは，IPv4 ならば DHCP に相当する機能である。IPv6 で導入さ
れたステートレス方式は，手作業で設定せずともホストに IPv6 アドレスを自動
的に設定する機能である。ルータ側での設定が多少必要となるが，この設定方式
では IP アドレス割り当てに DHCP サーバを必要としない。ホストが IPv6 アド
レスを生成するには，MAC アドレスやランダムに選択した ID といったホスト内
の情報とルータから得た情報を用いる。
13
128ビット
nビット
64-nビット
64ビット
Network Prefix
Subnet ID
Host ID
図 8 IPv6 アドレスフォーマット
これによりプレフィックス情報を変更する際には，ルータのプレフィックスを
変更し，新規プレフィックスを広告するだけで，今まで使用してきたプレフィッ
クスと共にサブネット ID を変更しなくてよい。また，ルータに繋がっているホ
ストは，自動設定機能を介して自らアドレス変更をする。また，後述するステー
トフルな DHCP と併用することも可能で，アドレスやプレフィックス以外のその
他のパラメータの設定も可能となる。本機能の真新しい点として，ノードに付与
される IPv6 アドレスに有効期限が伴うことが挙げられる。有効期限を過ぎれば，
そのアドレスは無効となり，重複確認の後新たなアドレスが付与される。そのた
め，このアドレスは一時的にしか有効でないことから一時アドレスとも言われる。
また，DHCP についても DHCPv4 と DHCPv6 の間に互換性はない。そのため，
デュアルスタックネットワークにおいて DHCP サービスを提供する場合，2 つの
プロトコル用にそれぞれの DHCP サービス運用が必要となる。この場合，設定
が競合しないように注意を払う必要がある。更に，DHCPv4 では DHCP を利用
して設定するかどうかはホスト側で決定するが，DHCPv6 では DHCP の利用は
ルータ広告のオプションで通知される。
なお表 3 に示すとおり，この DHCPv6 は R. Droms, Ed. らによって 2003 年に
提案されていた [26] が，一般的に広く使われているソフトウェアに標準で実装さ
れるようになったのは最近であり，やっと IPv6 においても広く従来通りのネット
ワーク管理が行えるようになったと言える。
14
表 3 DHCPv6 の標準化と実装時期
標準化/実装時期
RFC/ソフトウェア
2003 年 7 月
RFC3315
2006 年 11 月
Windows Vista 以降
2007 年 12 月
ISC DHCP 4.0.0 以降
2011 年 7 月
Mac OS X Lion 以降
2.3 IPv6 への移行前に考えるべき事
図 9 にクライアント―サーバ間のネットワークモデルを示す。インターネット
の初期は IPv4 のみで運用されてきた。その後，IPv6 が IPv4 アドレス枯渇の対策
として生まれた。しかしながら，上で述べた通り IPv4 とは異なるプロトコルで
あり，根本的に異なるプロトコルのため，IPv4 と IPv6 の両方で運用するデュア
ルスタックが用いられた。しかし，デュアルスタック運用には倍の運用コストが
かかることと，IPv4 アドレス枯渇が現実となった今，今後の運用を考慮すると，
IPv6 への移行が望まれる。
しかし，インターネット側のサーバやサービスの多くは IPv4 専用で動かされ
ており，この部分ではアクセス網としての IPv4 が残る。また，外部の管理者は手
を出すことができない領域となる。このとき，クライアント側が IPv4 でのサー
ビスを必要としていない場合は，NAT64/DNS64 を組み合わせることで，クライ
アント側及びコアネットワークは IPv6 のみで通信を行う事が可能となる。
ただ，現実問題としてクライアント側で IPv6 を完全に切ることはできない。理
由として，特に Skype に代表される音声系アプリケーションなどは，システム設
計が IPv4 アドレスと密接に関係しているものがある。これらは，シグナリング
などの管理プロトコルとして利用されていると考えられ，セキュリティの面など
から，単純に IPv6 のアドレスフォーマットへの対応が図れないものと考えられ
る [28, 29]。また，この他にも IPv6 への対応を行っていないサービス等も多々存
在する [30]。これらの問題を無視して IPv6 へ移行することは現実的ではないた
め，IPv4 が未だ必要な箇所，IPv4 を残した方が良い箇所，IPv6 へ移行すべきな
15
Customer
Core
CE
Client
Internet
BR
server
Client App
要v6対応
v4
v4/v6
v6
v6
v4/v6
クライアント側
v6対応不可
v4
v4/v6
v6
v6
v6
v4
v4/v6
v6
v4/v6
v4/v6
CE; Customer Edge
BR; Border Relay
図 9 クライアント―サーバ間のネットワークモデル
箇所に分けて整理する必要がある。
2.3.1 コアネットワーク
コアネットワーク（ここでは，プロバイダーコアネットワーク，エンタープラ
イズネットワーク，データセンターネットワークなどの人が常用しない内部ネッ
トワークを言う）は，IPv4 を残さなくとも問題のない場所，すなわち，IPv6 へ
移行すべきな箇所と言える。
こちらでは，専らサーバやネットワーク機器間の通信が行われ，それらが IPv6
での通信に対応していれば，コアネットワーク網内の機器間の通信は IPv6 で行
い，外へ出て行く際に，IPv6 から IPv4 の変換を行えば，コアネットワーク網で
利用するグローバル IPv4 アドレスを最小限に留め，網内の殆どは IPv6 化が行え
ることとなる。また，新たに構築するデータセンターネットワークにおいては，
すでに網内 IPv6 化が試みられている例もあり，実際の運用を行える状態にある
16
[31, 32]。
ただし，この場合においても Syslog の送信先や設定データのエクスポート先や
スイッチの各種設定 Web の URL として IPv4 しか設定できない場合もあるため，
プライベート IPv4 アドレス（NAT なし）が必要になることがある。これらは機
器ベンダーなどと共に調整しなければならない点であり，IPv6 のみの運用実現に
は時間を要する。
2.3.2 サーバ側ネットワーク
サーバ側ネットワークは，特にインターネットへサービスを提供している場合
には特に，IPv4 が必須と言える。
ここでは，理想を言うならば，IPv4 のみを使用している最後のノードが無くな
るまで，IPv4 アドレスでの運用を継続することとなる。最終的にロードバランサ
などのアプリケーションゲートウェイを利用するなどして IPv4 アドレス利用数
の削減を行う必要がある。これには十数年以上の時間が掛かるかもしれないが，
然るべき時期に AppleTalk など過去に使用されてきたプロトコルのように，OS
やソフトウェア側での IPv4 サポートを切り，IPv6 一本での運用を行えるように
業界全体で動く必要がある。
2.3.3 クライアント側ネットワーク
クライアント側ネットワーク，すなわちユーザ側はアプリケーションが IPv4 を
必要とするならば，IPv4 を残すべきネットワークである。
こちらは，まだまだ IPv4 でしかサービスされていないコンテンツが多々ある
ということと，IPv4 しか通信手段を持たないユーザがまだまだ圧倒的であるとい
う理由からである。しかし，基本的にこちらではサーバ群の様にグローバル IPv4
アドレスを残す必要は無く，NAT（GGN や IPv4 over IPv6 技術も含む）を利用
してプライベート IPv4 アドレスを利用できるだけでよいと考えられる。現時点
では多くの IPv4 利用者が NAT を経由した通信となっており，各利用者が何らか
のサービスを提供しない限り，グローバル IPv4 アドレスが必要になることはな
17
い。また，エンタープライズネットワークにおいて NAT44 や Proxy を導入して
いるネットワークでは，特定のサイトやポート以外とは通信断を行うなどの限定
的な利用を強いている場合もある。このような場合には，NAT64/DNS64 を使用
することで，速やかに IPv6 への移行が行える可能性がある。
2.4 IPv6 移行に向けた課題
2.4.1 グローバルアドレスを利用した通信
IPv4 ではアドレス数に限りがあるため，前述の通り，企業内や家庭内のクライ
アントノードは原則プライベート IPv4 アドレスが用いられ，ゲートウェイにて
NAPT44 (NAT) やプロキシが用いられるネットワークモデルが一般的であった。
そのため，期せずして外部からの直接のアクセスが容易ではない環境となってい
た。その結果，内部トポロジの隠匿にも貢献していた。
しかしながら，IPv6 はその豊富なアドレス量から，すべてグローバルアドレ
スを用いた運用が可能となるため，NAT を必要としない。IPv6 におけるネット
ワーク保護は既にで議論されており [33]，IPv4 における NAT 利用環境と同等な
状態を NAT なしで実現できることが示されている。
また，グローバルアドレスを利用することから，プライバシー問題を考慮する
必要があった。IPv6 の自動アドレス設定では，アドレスの下位 64 ビットをイン
ターフェースの MAC アドレスから生成する仕様であることから，上位のアドレ
スが変更されても，ノードが容易に特定可能となってしまう。
IPv6 における NAT の利用は，NAT66 が標準化されるなど，その需要に対応し
つつある。しかし，本来，NAT はセキュリティを高める為に提案された訳ではな
いため，NAT によってセキュリティが担保されるという考えは誤りであり [34]，
適切なフィルタリングが必要であると言える。
2.4.2 アドレス量の増加
IPv6 は 128 ビットのアドレス長を有することによって天文学的な数の IP アド
レスを表現している。更に，セグメントの最小単位がプレフィックス長 64 ビット
18
(/64) であるため，同一セグメントに最大 264 台のノードを収容することが可能
となる。
これにより，IP アドレスへのスキャニングを考えると，IPv6 は IPv4 と比べそ
の成功率は低く，無差別攻撃に対する耐性が向上すると言える [35]。ただし，こ
のことは攻撃者だけではなく管理者に対しても同じ働きをしてしまう。そのため，
管理面で何らかの対策を講じる必要が発生する。
また，一時アドレスを利用することで，頻繁に一時アドレスを変更することが
可能となり，送信元ノードの特定を困難にすることが可能となる。そのため，一
時アドレス機構を悪用して Denial of Service (DoS) 攻撃を行えば，発信元の特定
が困難になり，トラブルシュートを困難にすることが懸念されている [36]。
この課題を解決するためには，管理者はネットワークでの IPv6 アドレスの利
用状況を監視する必要がある。そのため，NDPMon[37] などの NDP 通信を監視
するソフトウェアを利用したネットワーク運用が望ましい。
2.4.3 マルチキャストを多用した通信
IPv4 においてもマルチキャストは存在したが，一般的に利用はされていなかっ
た。しかしながら，IPv6 ではマルチキャストを積極的に利用するプロトコルと
なっている。
加えて，IPv4 と大きく異なる点は，1 つのインターフェースに対して複数の IP
アドレスを利用出来る点にある。少なくとも，リンクローカルアドレスとグロー
バルアドレスの最低 2 つのスコープのアドレスが 1 つのインターフェースに IP ア
ドレスとして設定され，その上グローバルアドレスを複数設定することも可能で
ある。
以上の相違により，IPv4 では正しく動作したネットワーク環境においても，図
10 のように IPv6 では問題となる構成が存在する。IPv4 環境では，ユニキャス
トのみで通信を行っている場合が多く，同じ末端 HUB を利用していても異なる
ネットワークセグメントのパケットが届くことはない。しかし，IPv6 では，RA
がマルチキャストで配信されると，末端 HUB の全ポートに届くため，ノードに
は複数ネットワークセグメントのパケットが届き，各ネットワークセグメントの
19
セグメント A
セグメント B
router A
router B
intelligent switch
RA
末端HUB
PC A
PC B
図 10 RA がネットワークセグメントを超える構成
IP アドレスが割り振られてしまう [38]。
また，ルータの冗長化のために Virtual Router Redundancy Protocol (VRRP)
を使う場合も，VRRP と RA の兼ね合いでトラブルが発生するということがある。
具体的には，障害時に本番系から待機系に切り替わり，本番系に切り戻ったとき
に，その下にあるノードが本番系と待機系の両方のルータから RA を受け取って
しまい，すでに本番系に切り戻っているのに待機系のルータにパケットを送って
しまうことがある [31, 32]。
このような場合では，ネットワークをデュアルスタック化或いは IPv6 へ置き換
えの際，従来利用していた IPv4 のネットワークトポロジの見直しが必要となる。
2.4.4 IPv4 と仕様が異なる点での注意
IPv6 は IPv4 での運用知見を基に作られたとは言え，IPv6 において大きく異
なっている仕様も存在している。
まず，Internet Control Message Protocol (ICMP) の扱いが重要となってくる。
IPv6 では，ICMP を全て遮断すると通信が成り立たなくなる。特にルータでパケッ
20
トが分割できない仕様のため，通信路の MTU を探索する Path MTU Discovery
が必須であり，このためには Type 2 の ICMPv6 が必要となる。これは IPv4 にお
いて，DF ビットが設定されたパケット送信と同様であるが，IPv6 では全ての通
信が対象になるため重要と言える。表 4 に，フィルタリングすべきでないと示さ
れている ICMPv6 タイプを示す [39]。
表 4 フィルタリングすべきでない ICMPv6
ICMPv6 タイプ
コード
Type 1 (Destination Unreachable)
すべて
Type 2 (Packet Too Big)
Type 3 (Time Exceeded)
0 のみ
Type 4 (Parameter Problem)
1, 2 のみ
次にアドレス自動設定機構による自動アドレス設定に関しても，IPv4 と設定
できる項目に違いがある。IPv6 では RA を基に DHCPv6 によるアドレス設定を
制御するため，RA 利用が必須となる。表 5 に，それぞれの方式での設定可能項
目についてまとめる。
表 5 アドレス自動設定機構における設定可能項目の差異
設定項目
RA
デフォルト経路
○
アドレス
○
DHCPv6
×
○
5
プレフィックス長
○
サーバ情報
○
ルータ優先度
○
4
×
6
○
×
5
7
draft-ietf-mif-dhcpv6-route-option で標準化の検討中
プレフィックス情報よりアドレスを生成
7
draft-ietf-mif-dhcpv6-route-option で標準化の検討中
8
draft-ietf-mif-dhcpv6-route-option で標準化の検討中
9
RFC6918 で標準化
6
21
ICMP DHCP
○
○
×
○
×
○
×
○
○
8
-
このように DHCPv6 ではデフォルト経路を配布できないなどの差異が生じて
いるが，RA においてサーバ配布機能である RDNSS オプションの追加があった
ように，今後，必要に応じて機能拡張が DHCPv6 に対しても行われる可能性が
ある。実装面との課題でもあるが，IPv6 は現時点においても盛んに機能拡張が議
論されているため，仕様追加に伴う課題にも注意を向ける必要がある。
2.5 IPv6 移行に必要な要件
本章では，IPv4 の IPv6 への置き換えについて述べる。IPv6 はそのままでは
IPv4 と通信の互換性がないため，IPv4/IPv6 移行技術を用いて，両プロトコル
を変換しなければならない。移行のための技術の 1 つとしてトンネル技術が存
在し，大まかに IPv6 over IPv4 トンネルと IPv4 over IPv6 トンネルの 2 つに分
けることが出来る。しかし，本稿執筆時には IPv6 商用接続サービスが普及し，
IPv4/IPv6 を取り巻く環境も大きく変化したため，有志の Tokyo6to4[40] や商用
の OCN IPv6[41] といった 6to4 サービスが姿を消した。このことに加え，IPv6 が
一般となったときに，IPv6 over IPv4 トンネルの利用停止・撤退をしなければな
らないことならびに，IPv4 に代わって IPv6 の利用を推し進めるために，IPv6 で
の通信を基本とすることを考慮し，本節では，6to4, 6rd, Teredo 等の IPv6 over
IPv4 トンネルによる展開は考慮しないこととする。
図 11 に示した，IP 構成の推移であるが，インターネットの初期は IPv4 のみ
から発展していった。しかし，本学のように潤沢なグローバル IPv4 アドレスを
保有している場合では，今でもグローバル IPv4 アドレスから接続している場合
もある。本学ではほとんどのユーザが，グローバル IPv4 アドレスによる初期形
態で接続している。部分的にではあるが IPv6 を導入したデュアルスタックネッ
C
トワークとなっている箇所があり，一部，デュアルスタックネットワークから ⃝
のような形態で接続している例もある。こちらは，既存の IPv4 ネットワークに
加え，IPv6 を追加することで構築できる。今後，サーバサイドなどはこのような
ネットワークで構築されることも予想されるが，クライアントに関してはこのよ
うな構成は順次減ってくるものと考えられる。
しかし，インターネットが世間に広く普及するにつれて，IPv4 アドレスの枯
22
IPv6
IPv4
なし
NAT
あり
なし あり
N/A 目標
Ⓐ Ⓑ
初期 Ⓒ
図 11 IP 構成の推移
A のようにゲートウェイを介した接続を行うようになった。現
渇が問題となり，⃝
A では，まず，
在のインターネット接続形態の多くは，このような構成である。⃝
クライアントに対してプライベート IPv4 アドレスを適用し，インターネットへ
接続するためには，何らかのゲートウェイを介して通信するモデルになる。NAT
（IP マスカレード (NAPT) を含む）や Proxy サーバを介してグローバル IPv4 ア
ドレスとプライベート IPv4 アドレスの変換を行うことで，インターネットなど，
外部のホストと通信することが可能となる。
学術・研究機関のように IPv4 アドレスを潤沢に保有していても，近年の IPv4
アドレス枯渇により，アドレス体系の見直しと共に IPv6 を導入する場合もある
[42]。また，新規にネットワークを構築する際には大規模な IPv4 アドレスを配布
されることはない。このような場合では，IPv6 とプライベート IPv4 アドレスを
B の形態にすることができる。ここでは，クライアントマ
組み合わせた図 11 の ⃝
シンに NAPT44 を介したプライベート IPv4 アドレスと IPv6 アドレスを提供す
る。IPv6 で接続できるものについては IPv6 で接続し IPv6 での接続が不可能な
場合，NAPT44 経由の IPv4 接続となる。この場合，内部にサーバを置くなどグ
ローバル IP アドレスを必要としない場合は，満足にインターネットを利用でき
23
(a) IPv4 での接続
(b) IPv6 での接続
図 12 接続方式における閲覧結果の違い
る。しかし，これではネットワーク全体に IPv4 と IPv6 が存在していることとな
り，2 つのプロトコルバージョンを運用保守しなければならず運用コストやセキュ
リティ対策が煩雑になるという問題が出る。
そこで，図 11 の目標の段階へと持ち込むことを考える。現状，IPv6 に対応し
ているサービスは少なく，Google 検索10 のように，検索ページは対応していても，
検索クエリの回答ページにあるリストが IPv6 に対応していない場合には，IPv6
でアクセスできない。また，Google の場合，多くのサービスが IPv6 への対応を
済ませているが，Google Scholar11 のように IPv4 でのみ提供されるサービスも存
在する。この他にもトップページは IPv6 対応しているが，中のコンテンツや埋め
込みコンテンツの IPv6 化がなされておらず，IPv6 のみでは満足にページを閲覧
できないという問題がある。図 12 は，実際に http://www.au.kddi.com/ にアク
セスを行った際のキャプチャ画像であるが，IPv4 で接続を行った場合には，(a)
のように全てのコンテンツが閲覧できた。しかしながら，IPv6 で接続を行った場
合には，(b) のようにサイトへのアクセスは行え，Web ページのレイアウトは確
認できるが，肝心のコンテンツ部分に関する情報が一切得られなかった。
このような場合での IPv6 による IPv4 の置き換え手法としては，図 13 のよう
10
11
http://www.google.co.jp/
http://scholar.google.co.jp/
24
IPv4 Internet
IPv6 Internet
IPv4通信
IPv4/IPv6共存技術
IPv6 Only Network
IPv6通信
Server
Server
PC
PC
PC
PC
図 13 IPv6 ベースネットワークのイメージ
に IPv4/IPv6 移行技術を利用することが挙げられる。まず，コアネットワークお
よびユーザが利用するネットワークには，基本的に IPv6 アドレスを配布し，イ
ンターネットを利用させるものとする。このとき IPv4 インターネットとの接続
は IPv6 アドレスと IPv4 アドレスを変換しユーザに提供する NAT64/DNS64 と，
IPv6 コアネットワークを超えて IPv4 ネットワークをユーザに提供する 464XLAT，
SA46T による変換を行うことで通信を確保できる。
表 6 に，文献 [43] で挙げられている各セグメントのサービスプロバイダでの要
件比較を行う。この中では，ISP とモバイルオペレータそして一般企業が比較さ
れている。一般に言われていることであるが，ISP やモバイルオペレータといっ
た回線提供側は IPv6 の導入を行い，IPv6 回線の提供も行っているが，ネットワー
クのユーザ側である一般企業では，IPv6 化が遅れている。これは，一般企業に
限ったことでは無く，大学等の学校や一般家庭においても同様のことが言える。
25
表 6 各セグメントのサービスプロバイダの考慮事項
要因
モバイル
一般企業
ISP
IPv4
今 ― 現在、IPv6
不定 ― ゲート
今 ― NAT と
アドレス枯渇
アドレスが端末で
ウェイで NAT
IPv6 CPE の
への対応
利用可能
されている
組み合わせ
IPv6 コンテンツ
と対応アプリ
遅い。自社の
急成長
オンプレミス
ケーション
デバイス/CPE
の更新頻度
急成長
サービスの対応
高い
低い
26
低い
3. IPv6 移行関連技術
ここでは，関連技術として IPv6 移行技術について述べる。表 7 に IPv4/IPv6 移
行・共存技術の区分けを示す。まず，上側の 2 つはバックボーンを IPv4 で構築し
ていることを前提としている。その上で，ISP などのバックボーン側ネットワー
クからユーザ側ネットワークまでを，グローバル IPv4 アドレスから NAT44 され
た ISP Shared アドレスへと変更し，疎通性を提供する CGN を利用し，IPv4 ア
ドレスの利用数を削減した手法である。また，6rd については，IPv4 のみのバッ
クボーン上で，IPv6 を利用する際にトンネル技術を利用して，IPv4 ネットワー
クから IPv6 ネットワークへの疎通性を得る手法である。これらは，IPv4 をメイ
ンとしている。2.5 節でも述べた通り，本論文では将来性を加味し，IPv4 Sunset
を推し進めるため，IPv6 での通信を基本とし，6to4, 6rd, Teredo 等の IPv6 over
IPv4 トンネルによる展開は考慮しないこととする。
表 7 IPv4/IPv6 移行・共存技術
適用手法
クライアント側
バックボーン側
サーバ側
CGN
IPv4
IPv4
IPv4
6rd
IPv6
IPv4
IPv6
MAP, 464XLAT, DS-Lite, SA46T
IPv4
IPv6
IPv4
NAT64
IPv6
IPv6
IPv4
3.1 IPv6 移行関連技術の棲み分け
図 14 に示した様に，現在，IETF では様々な IPv4/IPv6 移行共存技術が提案
されている [44]。
これらの各技術はそれぞれ異なった特徴を持つ。ただし，それぞれに優劣を付
けられるものでは無く，利用に際しては，移行・共存技術を導入する場所，規模，
事業者の特性に合ったものを適切に選択する必要がある。
27
MAP-DHCP
MAP
MAP-DEPLOYMENT
IVI
dIVI
dIVI-pd
MAP-T
NAT64
XLAT464
MAP-E
SAM
NAT-PT
4rd
Public 4over6
NAT464
DS-lite
4rd-(H,U)
Lightweight 4over6
Stateless DS-lite
A+P
6to4 (RFC3056)
6rd (RFC5969)
Configured tunnels
RFC1933
Automatic tunnels
6over4
ISATAP
Tunnel brokers
Teredo
BGP tunnels
Softwire mesh
6PE
6VPE
図 14 移行技術の推移
各技術の利用を判断するポイントは以下にある。
• ステートフル変換（IP マスカレード）を行う場所
• トランスレーション・カプセル化
• ステートレス・ステートフル
ステートフル変換を行う場所
IPv6 移行技術では，ステートフル変換を行う場所は，図 15 のように (A) サー
ビス提供側のバックボーンで行うものと，図 16 のように (B) ユーザなどのサー
ビス利用側で行うものに分かれる。
28
IPv4 Internet
BR
BR
NATポイント
CE
CE
CE
CE
Dual stack
Dual stack
Dual stack
Dual stack
図 15 NAT センター集約型
(A) の場合には，NAT セッションをバックボーンで管理するため膨大なログ
取りが必要となる。そのためには大規模ストレージが必要となり，スケーラビリ
ティが低いものとなる。また，バックボーン側機器が NAT セッションを保持して
いるため，バックボーン側機器のファームウェア更新時などにトラブルが発生す
ると，ユーザの NAT セッションが破棄される恐れがあるなど運用上の注意点が
増えることとなる。しかしながら，セッションを一括管理しているため，通信不
良や不正通信時の追跡は容易なものとなる。更に，ユーザに割り当てるポート数
を柔軟に制御することが可能で，グローバル IPv4 アドレスの有効な活用が期待
できる。このため中小規模の ISP や，閉じた範囲内にサービスを提供しているエ
ンタープライズネットワークやキャンパスネットワークに適していると言える。
(B) の場合には，アドレスマッピングルールを予め設定しておくことで，ユー
ザ自身が割り当てられた IPv6 アドレスから使用可能なグローバル IPv4 アドレ
スとポート番号の範囲が導出でき，ユーザ側の CPE で NAT を行う。キャリアは
単純にアドレスマッピングを行うシンプルな機器でルーティング可能となる。ス
29
IPv4 Internet
BR
BR
NATポイント
CE
CE
CE
CE
Dual stack
Dual stack
Dual stack
Dual stack
図 16 NAT 分配型
ケーラビリティを確保しやすい。ユーザが利用するポート番号の範囲のみを管理
すれば良く，膨大な NAT セッションを扱う CGN もログを保存するストレージも
必要ない。しかし，予めアドレスマッチングルールを事前に決める必要がある。
後で変更することも困難なため，IPv4，IPv6 共に大規模なアドレスレンジを保
有している必要がある。このため，大規模 ISP に適していると言える。
トランスレーション・カプセル化
(a) トランスレーション
(b) カプセル化
図 17 トランスレーション・カプセル化の模式図
30
トランスレーションとは，図 17 (a) のように，文字通り IPv4 パケットを IPv6
パケットに変換して運ぶ技術である。この方法では，IPv6 ネットワーク上でペイ
ロードを直接扱うことができる。そのため，IPv6 コアネットワーク上で IPv6 の
Access Control List (ACL) を用いたアクセス制限や帯域確保のための Quality of
Service (QoS) 制御が容易にでき，ACL 制限や QoS 制御のためにカプセル化され
たペイロードを Deep Packet Inspection (DPI) で確認する必要がなくなる。ただ
し，ヘッダは IPv4/IPv6 の差分だけ増えしか増えないが，代わりに IPv4 ヘッダ
の情報が欠落する。
カプセル化は，図 17 (b) のように，IPv4 パケットを IPv6 パケットで包み込
んで運ぶ技術である。こちらはトンネル技術とも言われる。元のパケットをその
まま運ぶため，IPv4 のヘッダ情報が欠落しないという利点がある。また，チェッ
クサムの再計算が不要となる。IPv6 でカプセル化した分量のヘッダ情報が増える
こととなる。ただし，近年のバックボーンでは MTU の増大化が盛んに行われて
いるため，大した問題にはならないと考えられる。
ステートレス・ステートフル
まず，以下にステートレス（図 18 (a) ）の利点を挙げる。
• Anycast などの既存技術を用いた冗長化が可能
• 悪意あるユーザにポート番号を占有されない
• ポートアサインのログを保管しなくてよい
• 多数収容するバックボーン側でステートを持たないためスケールする
• セッションベースではなく，トラフィックベースでの設備投資が可能
次に，ステートフル（図 18 (b) ）の利点を挙げる。
• ポート数がユーザごとに固定されていないのでより少ない IPv4 アドレスで
サービスの提供が可能（dynamic allocation の場合）
• CPE 機器の実装が簡易，安価になる
31
ステートレス
Client
IPv4
IPv6
IPv4
server
Internet
ステートフル
(a) ステートレス
ステートフル
Client
IPv4
IPv6
IPv4
server
Internet
ステートレス
(b) ステートフル
図 18 ステートレス・ステートフルの模式図
3.2 主要な IPv4/IPv6 移行共存技術
本節では，標準化が進められている（或いは RFC 化が完了している）主要な
IPv4/IPv6 共存技術について述べる。ここで述べる多くの技術は，IPv4 over IPv6
技術と言われ，ISP などの多数のユーザを持つ事業者が IPv4 の消費を抑えなが
ら，なおかつデュアルスタックで数多くの顧客を収容する手法として注目されて
いる。
3.2.1 NAT64
NAT64 は IPv6 ネットワークから IPv4 ネットワークへアクセスする際に使用
する IPv6 から IPv4 へ変換するステートフルな NAT である [45]。そのため，通信
の発信元を IPv6 側に限定し IPv6/IPv4 変換のみを定義している。NAT64 ネット
ワーク下のホストは図 19 のように，IPv6 ネットワークのみで完結でき，基本的
に IPv6 アドレスを利用して通信を行う必要がある。そのため，DNS については
DNS64[46] に対応した DNS サーバに問い合わせを行わなければ，インターネット
32
DNS応答/
DNS64
レコード変換
Client
IPv4
IPv6
server
NAT64
Internet
ユーザ側
IPv6 core
パケット
変換
図 19 NAT64/DNS64 の模式図
上の IPv4 ホストと通信することができない。NAT64 ではそれぞれ，32, 40, 48,
56, 64, 96 bit の各 Prefix 長で設定が可能である。なお，96bits Prefix の場合は図
20 のようになる。
96 bits
32 bits
IPv6 prefix
c0a8:221
192.168.2.33
図 20 NAT64 におけるアドレス変換
NAT64/DNS64 の動作を，図 21 に示す。
Arkko らの先行研究 [28] より，DNS 登録されていない IPv4 アドレス表記に
対する変換は DNS64 では行えず，通信が不可能となることが明らかとなってい
る。Wing によると，2.38%の Web サイトが IPv4 アドレス直書きであることが
報告されている [47]。しかし，この問題に対しては IPv4 アドレスリテラル変換
DNS が提案されており，例えば，198.51.100.50 というアドレス表記に対しては，
198.51.100.50.sixxs.org と置き換えることで，NAT64/DNS64 を使うことができる
[48, 49]。
33
IPv6
NAT64/DNS64
IPv4（グローバル）
IPv6専用クライアント
IPv4サーバ
www.example.com ?
www.example.com ?
AAAA = IPv6
A = IPv4
64::ff9b::cb00:717b
203.0.113.123
宛先 64:ff9b::cb00:717b :80
送信元 2001:db8::192.168.1.10 :2222
宛先 203.0.113.123 :80
送信元 198.51.100.111 :2222
図 21 NAT64/DNS64 の変換の仕組み
34
DNSサーバ
3.2.2 464XLAT (464NAT)
Client
IPv4
ユーザ側
CLAT
ステート
レス46変換
IPv6
IPv6 core
PLAT
IPv4
NAT64
server
Internet
図 22 464XLAT の模式図
464XLAT は IPv4/IPv6 変換と NAT64 を組み合わせた IPv4/IPv6/IPv4 変換技
術である [50]。そのため，NAT64/DNS64 の環境が既に整っている環境には，導
入が容易と言える。図 22 のように，宛先が IPv4 ネットワークの場合，コアネッ
トワークの IPv6 を越えて IPv4 ネットワークを利用する形となる。NAT64 と違
い，IPv4-IPv4 の通信となるため，DNS64 は不要である。ユーザ側に Customer
side translator (CLAT) ，コアネットワーク側に Provider side translator (PLAT)
を配置する。動作はユーザ側の CLAT でプライベート IPv4 アドレスからグロー
バル IPv6 アドレスへの 1 : 1 のステートレスな変換を行い，コアネットワーク側
の PLAT で NAT64 によるグローバル IPv6 アドレスからグローバル IPv4 アドレ
スへの 1 : n のステートフルな変換を行う。PLAT および CLAT については同様
に，キャンパスネットワーク運営側で準備するものとする。
464XLAT は，Skype が利用出来ない [51] という問題が報告されていたが，現
時点では，464XLAT を利用した IPv6 越しの Skype の利用が可能となっている
[51, 52]。
3.2.3 MAP-T
まずは，MAP-T の説明を行う前に Mapping Address and Port (MAP) につい
て説明を行う。MAP ではパケットの運び方には触れずに，IPv6 アドレスに対す
る IPv4 アドレスとポート番号情報の埋め込み方 (forward mapping rule; FMR)
35
と，アドレスから送信元ポートを決める port mapping algorithm を統一して決め
ている。それぞれ，FMR と port mapping algorithm を図 23 と図 24 に示す。
32bits
16bits
IPv4 destination address
IPv4 dest port
p bits
q bits
IPv4 sufx
Port-Set ID
n bits
o bits
s bits
Rule IPv6 prefix EA bits subnet ID
128-n-o-s bits
interface ID
End-user IPv6 prefix
図 23 MAP における FMR
MAP では図 23 のように IPv6 アドレスに IPv4 アドレスを埋め込むが，IPv4
アドレスの 32 ビット全ては入りきらないため，ホスト部分 (suffix) だけを IPv6
アドレスに埋め込む。ここで入りきらなかったネットワーク部分の情報は，Basic
Mapping Rule (BMR) と呼ばれる IPv6 アドレスと IPv4 アドレスを紐付けるマッ
ピング規則に基づいて，IPv6 プレフィックス，IPv4 プレフィックス，EA bits 長
の組をバックボーン側の Border Relay (BR) とエンドユーザ側に Customer Edge
(CE) とで共有しておく。IPv4 では，IPv4 Prefix に合致したら，残りの suffix と
設定された PSID で EA bits を構築する。IPv6 では，IPv6 Prefix に合致したら，
続く EA bits 長のうち 32-prefix 長を切り出して，IPv4 suffix を埋めた後，残りを
PSID として扱う。
このため，IPv4, IPv6 共に広帯域のアドレス空間を配備可能な大規模 ISP など
の環境に適している。なお，EA bits の余った部分に利用可能なポート番号の範
囲の情報である Port Set ID (PSID) を埋め込む。
PSID は図 24 のように，16 ビットポート番号の中に埋め込まれた k bits の識
別子であり，この情報を用いてポート番号の制限を行う。ここで A はオフセット
であり，存在するときは A は 0 以上の値とする。これは，システムポートの利用
36
0
1
01234567890123456
Ports in the
CE port set
A
>0
a bits
PSID M
k bits
m bits
図 24 MAP における port mapping algorithm
を避けるためである。
なお，MAP では Rule IPv4 prefix の長さと EA-bits の長さにより，CE に渡さ
れる IP アドレスの種類が決まる。図 25 (a) のように，Rule IPv4 prefix length
+ EA-bits length >32 のときは，Shared IPv4 address と呼ばれ，複数の CE で
1 つのグローバル IP アドレスを共有する。図 25 (b) のように，Rule IPv4 prefix
length + EA-bits length = 32 のときは，Complete IPv4 address と呼ばれ，1 つ
の CE で 1 つのグローバル IP アドレスを占有できる。図 25 (c) のように，Rule
IPv4 prefix length + EA-bits length <32 のときは，IPv4 prefix と呼ばれ，1 つ
の CE で複数のグローバル IP アドレスを使用できる。例えば、Rule IPv4 prefix
length が/24 で EA bits length が 4 のとき/28 の IPv4 prefix が割り当てられる。
MAP-T は，MAP に準拠した IPv4/IPv6/IPv4 変換技術である [53]。図 26 に概
略図を示す。アドレスフォーマットとポートマッピングが MAP に準拠している。
エンドユーザ側に Customer Edge (CE) を，バックボーン側に Border Relay (BR)
を置き，CE 側でステートフルな NAPT44 が実行される。また CE では，MAP の
FMR に則って IPv4/IPv6 変換が行われ，BR にてステートレスな IPv6/IPv4 変
換が行われる。
なお，各 CE 側が NAT ポイントとなるため，メッシュトポロジをサポートして
おり，ユーザ同士は低遅延で直接通信することが可能である。加えてトラフィッ
クは IPv6 網内で折り返しとなるため，バックボーン側機器のリソースを消費せ
ずに済む。
37
Rule IPv6 Prefix
EA bits
Subnet ID
Interface ID
IPv6アドレス
Rule IPv4 Prefix
IPv4アドレス
PSID
ポート
(a) Shared IP address
Rule IPv6 Prefix
EA bits Subnet ID
Interface ID
IPv6アドレス
Rule IPv4 Prefix
IPv4アドレス
(b) Complete IP address
Rule IPv6 Prefix
EA
bits Subnet ID
Interface ID
IPv6アドレス
Rule IPv4 Prefix
IPv4アドレス
(c) IPv4 prefix
図 25 MAP における IPv4 アドレスの配り方
38
Client
IPv4
CE
IPv6
ユーザ側 MAPによるステート IPv6 core
フルNAPT44+46変換
IPv4
BR
server
Internet
ステートレス
64変換
図 26 MAP-T の模式図
3.2.4 DS-Lite
DS-Lite は IPv4 over IPv6 と Carrier Grade NAT (CGN) を組み合わせた技
術である [54]。図 27 に概略図を示す。名称の DS-Lite は通常の Dual Stack より
簡易 (Lite) に Dual Stack を実現できることから来ている。エンドユーザネッ
トワーク側に Basic Bridging BroadBand (B4) と呼ばれる Consumer Premises
Equipment (CPE) 機器を設置し，バックボーン側に Address Family Translation
Router (AFTR) を設置する。
Client
IPv4
B4
IPv4 over IPv6
ユーザ側 IPv4 over IPv6 IPv6 core
カプセル化
AFTR
IPv4
server
Internet
IPv4 over IPv6
デカプセル化 + CGN
図 27 DS-lite の模式図
動作としては図 28 に示す通り，B4 で IPv4 over IPv6 のカプセル化を行い，設
定された AFTR にパケットを転送する。その後，AFTR ではカプセル化を解除
し，NAPT44 を行う。AFTR による NAPT では，トンネル側の B4 側の IPv6 ア
ドレスでどのエンドユーザネットワークかを区別する。AFTR と B4 とのトンネ
ル間の IPv4 アドレスブロックは 192.0.0.0/29 を用いる。AFTR の IPv4 アドレス
39
については 192.0.0.1 を，B4 の IPv4 アドレスについては 192.0.0.0/29 の内の残り
を使用する必要がある。
IPv6 キャリア/
IPv4プライベート
IPv4グローバル
バックボーン
B4
192.168.1.1
IPv4ヘッダ
送信元 192.168.1.1
宛先 198.51.100.99
AFTR
203.0.113.11
2001:db8:a10:a10::99
2001:db8:192:168::1
IPv6ヘッダ
送信元 2001:db8:192:168::1
宛先 2001:db8:a10:a10::99
198.51.100.99
IPv4ヘッダ
送信元 203.0.113.11
宛先 198.51.100.99
IPv4ヘッダ
送信元 192.168.1.1
宛先 198.51.100.99
図 28 DS-Lite のフロー
3.2.5 MAP-E
MAP-E は MAP に準拠した NAPT44 と IPv4 over IPv6 を組み合わせたカプセ
ル化技術である [55]。図 29 に概略図を示す。MAP-T と同様で，アドレスフォー
マットとポートマッピングが MAP に準拠しており，エンドユーザ側に CE を，
バックボーン側に BR を置き，CE 側で NAPT する。
動作は，エンドユーザ側の CE でステートフルな NAPT44，IPv4 over IPv6 カ
プセル化を行い，IPv6 バックボーンを超える。BR では IPv4 アドレスからステー
トレスに IPv6 アドレスを求めてカプセル化し CE に転送する。
MAP-T 同様，各 CE 側が NAT ポイントとなるため，メッシュトポロジをサ
ポートしており，同網内においても低レイテンシで通信が可能となる。
40
Client
IPv4
CE
IPv4 over IPv6
IPv6 core
ユーザ側 MAPによるステートフルNAPT44 +
IPv4
BR
server
Internet
ステートレス IPv4
over IPv6デカプセル化
IPv4 over IPv6カプセル化
図 29 MAP-E の模式図
3.2.6 SA64T
SA64T は，ステートレス IPv4 を IPv6 に変換することにより IPv6 網で IPv4 通
信を実現する技術である [56, 57]。バックボーン側をデュアルスタックにするこ
となく，端末間の IPv4 通信を行うことが可能となる。
Client
ユーザ側
IPv4
SA46T
IPv4 over IPv6
ステートレス IPv6 core
46変換
SA46T
IPv4
64
変換
server
Internet
図 30 SA46T の模式図
SA46T は IPv4 パケットのカプセル化およびデカプセル化を行う IPv4 over IPv6
技術である。図 30 のように，IPv6 コアネットワークと IPv4 ホストが存在するネッ
トワークの境界に導入することで IPv6 を超えて IPv4 への到達性を得る。SA46T
は NAT64 などのように IPv4 only ホストと IPv6 only ホストとの通信は出来ず，
IPv4 only ホストと IPv4 only ホスト間の通信もしくは，IPv4 only ホストとデュ
アルスタックホスト間の IPv4 通信の通信を，IPv6 バックボーンを超えて実現す
る。そのため，IPv6 の通信に SA46T は関与しない [57]。
他の仮想的なリンクを用いるカプセル化技術とは異なり，図 32 にある IPv4 ア
ドレスのロケータとアイデンティファイアの構造を維持したまま，IPv6 アドレス
41
IPv4
IPv4 IPv6
IPv4
Stub Network
(IPv4 only)
IPv6 IPv4
Backbone Network
(IPv6 only)
SA46T
図 31 SA46T の機能
空間にマッピングする。なお，先と同様に SA46T 装置については，キャンパス
ネットワーク運営側で準備するものとする。
3.3 IPv4/IPv6 移行技術の現状
前節において主要な IPv4/IPv6 移行技術を紹介した。図 14 に示されているよ
うに，トランスレータ型の中での拡張や，トンネル型の拡張など様々な方式が提
案されている。
ここでは，これらの技術の整理および比較・検討を行う。
3.3.1 IPv4/IPv6 移行技術の比較
表 8 に，これまで挙げてきた IPv4/IPv6 移行・共存技術の比較を行う。
3.1 節でカプセル - トランスレート， ステートレス - ステートフル，ステート
フル変換ポイントという各移行技術の利用を判断するポイントを説明した。表 8
でのそれぞれの利点・欠点は上記のポイントから来ている。MAP-T, MAP-E や
42
32bits
IPv4 address
128bits
Locator (IPv4; 24bits)
SA46T address prefix IPv4 network plane ID
Locator (IPv6; 120bits)
Identifier
IPv4 address
Identifier
図 32 SA46T アドレス構造
SA46T は NAT 分配型で，それ以外の技術は NAT センター集約型となる。NAT
分配型は図 33 のようなメッシュ型ネットワークと言うことができ，従来の NAT
の様に，各スタブネットワークにおいて NAT 化されているため，同じ IPv6 網内
に居る相手と通信する際に，各スタブネットワーク同士で通信を行う事ができる。
そのため，リソースの消費が少なく，低遅延で網内のネットワークを通信するこ
とが可能である。
対して NAT センター集約型は図 34 のようなハブ＆スポーク型ネットワーク
と言うことができ，NAT をバックボーン側で行うため，同じ IPv6 網内に居る相
手と通信する際においても，バックボーン側の機器を介して通信をする必要があ
る。しかし，トラフィックがバックボーン側機器を常に通るため，通信不良等が
発生した場合の確認がしやすい。
これらより，クライアントネットワークを v6 化したい場合には NAT64/DNS64
を，クライアントネットワークで部分的に v4 が欲しい場合には NAT64/DNS64
+ 464XLAT の組み合わせを，クライアントネットワークで全体的に v4 が欲し
い場合には DS-Lite を，従来 IPv4 プライベートでの構成が主であった場合には
SA64T を，高付加価値サーバを多く収容する場合には MAP-E, MAP-T を利用す
れば良いのではないかと考えられる。
43
表 8 IPv4/IPv6 移行・共存技術の比較
NAT64 464XLAT MAP-T MAP-E DS-Lite SA46T
利点
メッシュ化
メッシュ化 クライアント
NAT64環境と メッシュ化
環境に適して 既存のNAT技
親和性が高い
Anycast等
Anycast等
いる
IPv6 onlyな
術と組み合わ
ネットワーク ユーザ側機器 既存の冗長化 既存の冗長化
せ可能
手法を利用で 手法を利用で ユーザ側機器
の実装が簡易
きる
きる
の実装が簡易 プロトコル透
過性が高い
欠点
DNS64が必
須
ステートフル ユーザ側機器 ユーザ側機器 NATが複数段
あるため、 クライアント
なので既存の
環境へは2重
Skypeなどの 冗長化手法が の実装が簡易 の実装が簡易 サービスネッ NATが提案さ
音声系アプリ 使えない
ではない
ではない トワークには れている
には対応して
不向き
いない
3.3.2 IPv4/IPv6 移行技術の乱立
図 14 のように，IPv4/IPv6 移行技術は様々な規格が提案・統廃合され，変遷
している。ドラフト状態では乱立してはまとめられる状況であり，すぐさま定常
運用に使える規格ばかりではない。今現在も，図 35 のように規格の提案・整理
が行われている。
3.4 IPv4/IPv6 移行技術に共通する問題
3.4.1 MTU 問題
図 36 に示すように MTU の違いによるパケットフラグメント問題が発生する。
カプセル化，トランスレートを問わず，ヘッダのサイズが変わる。カプセル化
では+ 40 バイト，トランスレートでは+ 20 バイト増えることとなる。そのため，
IP のペイロードのサイズが MTU 限界に近い場合だとフラグメントされる。特に
フラグメントの概念がない IPv6 へのトランスレートでは，パケットが破棄され
るなどの問題が生じる。また，TCP の場合は MTU から TCP/IP ヘッダ (40byte)
44
IPv4 Internet
BR
IPv6 Core Network
Mesh
CE
CE
Customer
Customer
Network
Network
図 33 メッシュ型ネットワーク
を間引いた値である Max Segment Size (MSS) 部分にユーザデータを格納する。
そのため，TCP では MSS を MSS Clamping で MSS 値を調整する。ステートフル
技術ではこれをバックボーン側で対応することができるが，MAP などのステー
トレス技術ではどこで対応するのか，また UDP の場合は救えないという欠点も
ある。
3.4.2 NAPT 問題
すべての IPv4/IPv6 移行技術でグローバル IPv4 アドレスの共有のために NAPT
を使用しているため，ポート番号を持っていない上位のプロトコルは個別対応が
必要という NAPT の問題を抱えている。特に L2TP, PPTP では対応していない
場合が多く，IPSec も NAPT の場合は UDP で包む仕様であるが，クライアント
によっては対応していない場合がある。
45
IPv4 Internet
BR
IPv6 Core Network
Hub & Spoke
CE
CE
Customer
Customer
Network
Network
図 34 ハブ＆スポーク型ネットワーク
NATの CPE MAP-E MAP-T
場所 バック DS-Lite 464XLAT
ボーン
統一される見込み
図 35 規格の整理
46
4rd
（元4rd-U）
IPv4
MTU 1500 DF Not Set
Router Packet Fragment
MTU 1500MTU 1400 MTU 1400
MTU 1500
DF Set
ICMPv4 Fragment Needed
PATH MTU Discovery
MTU 9216
MTU 9216
MTU 5120
MTU 9216
MTU 5120
ICMPv6 Packet Too Big
途中のルータで
パケットフラグメント
IPv6
End-Endで
パケットフラグメント
IPv6
変換装置で
調整が必要
Fragment Needed
Packet Too Big
強制的なフラグメントMSS Clamping
図 36 MTU 問題
47
4. IPv6 移行関連技術によるネットワーク運用
本章では，現状のブロードバンドネットワークのトラフィックの内訳を示した上
で，3 章において説明した IPv6 移行関連技術を使用したネットワーク運用につい
て述べる。特に，モバイル回線は Universal Mobile Telecommunications System
(UMTS) や Long Term Evolution (LTE) と呼ばれる通信方式において IPv6 の利
用がサポートされている [58, 59]。スマートフォンやタブレットなど IP アドレス
を必要とする端末は年々増加しているため，IPv6 の普及が進んでいる [60]。
4.1 ブロードバンドネットワークの内訳
近年では，ブロードバンドネットワークのトラフィックの内訳は様変わりして
おり，旧来では教科書モデルと言われるインターネットの中心にいる世界の大手
プロバイダである Tier1 を中心にトラフィックが集中していたが，近年ではトラ
フィックの中心が Tier1 からコンテンツを持つ Hyper Giants 中心のネットワーク
に変化している [61]。更にスマートフォンやタブレット端末，ウェアラブル端末
の登場によってモバイルトラフィックの内訳が大きく増加することが予想される。
図 37 と表 9 に商用 ISP が公開しているポート別のブロードバンドトラフィッ
クを示す [62, 63]。ネットワーク全体のトラフィックは，ピア型の一部のヘビー
ユーザのトラフィックに支配されているため，本データにおいては，1 日のアッ
プロード量が 100MB 未満の一般的なユーザをクライアントとして抜き出してい
る [62, 63]。図 37 では下側が，表 9 では右側がそれぞれクライアントにあたる。
これらのデータを見ると，全体的に 80 番ポートの内訳が増えており，この傾
向はインターネット全体のトレンドが変わらない限り，今後も増加が考えられる
と言える。
2011 年から 2013 年の 3 年間のトラフィックはどれも，TCP が 80%近くである。
更に全体で見ると，2011 年には総量の約 50%であった TCP の動的ポートが 2012
年には約 41%に，2013 年には約 30%にまで減少した。動的ポートでの個別のポー
ト番号の割合は僅かで，Adobe Flash Player が利用する 1935 番が最大で総量の
約 1.5%, 2.1% 2.4%と増えてきているが，その他は 0.5%未満となっている。逆に
48
80
TCP < 1024
TCP > 1024
UDP
others
2011
2012
2013
0
25
50
75
100
全体
80
TCP < 1024
TCP > 1024
UDP
others
2011
2012
2013
0
25
50
75
クライアント
図 37 ポート別のブロードバンドトラフィック（概要）
49
100
表 9 ポート別のブロードバンドトラフィック（詳細）
ポート番号
2011
total (%)
2012
2013
client total (%)
client total (%)
client
TCP
85.85
96.28
81.86
95.09
79.79
96.91
(> 1024)
36.24
85.69
41.23
85.25
49.57
88.15
80 (http)
32.10
67.30
36.22
79.39
43.44
81.61
443 (https)
1.33
1.91
2.45
3.43
3.90
4.80
554 (rtsp)
1.33
6.89
0.77
1.01
0.51
0.58
22 (ssh)
0.27
0.17
0.22
0.06
0.24
0.04
(≥ 1024)
49.71
10.59
40.63
9.84
30.22
8.76
1935 (rtmp)
1.58
1.51
2.12
3.91
2.39
3.60
7144 (peercast)
0.38
0.00
0.44
0.04
0.40
0.04
6346 (gnutella)
0.68
0.60
0.37
0.09
-
-
8080
0.26
0.14
0.30
0.17
0.34
0.19
UDP
10.01
2.61
12.38
2.94
13.21
2.12
ESP
3.56
1.02
5.29
1.79
6.54
0.88
GRE
0.15
0.05
0.16
0.14
0.20
0.06
L2TP
0.13
0.00
0.14
0.00
0.13
0.00
IP-ENCAP
0.10
0.01
0.09
0.01
0.09
0.00
50
80 番ポートの割合は，2011 年から 2013 年までそれぞれ約 32%, 36%, 43%に増加
している。なお，TCP 以外のトラフィックのほとんどは VPN 関連で，増加傾向
にある [63]。
クライアントデータを見れば 2011 年に 67%を占めていた 80 番ポートの通信が，
2012 年では約 80%近くになっている。また，2013 年のデータでは，80 番ポート
の通信が 80%を超えている。この理由としては，ビデオコンテンツやソフトウェ
アアップデートが 80 番ポートの通信に含まれるため，コンテンツタイプの内訳
は分からないが，80 番ポートで通信を行うサーバが多くなったからと言える。ま
た，その用途からヘビーユーザの利用率も大きくなってきていることが考えられ
る。言い換えるならば，大部分のクライアント側の通信に関しては，NAT64 等を
利用して IPv6 ネットワークへの置き換えが行えるということになる。クライア
ント通信の IPv6 化を考慮し次節からは，現時点での IPv6 移行技術を用いたネッ
トワーク運用の知見について述べる。
4.2 IPv6 移行関連技術を用いたサービス
本節では，IPv6 移行関連技術を利用してサービス展開をしている例を示す。
4.2.1 Android CLAT
Android CLAT は，前章で説明した 464XLAT の CLAT をハードウェアではな
く，ソフトウェアとして Android にて実装したものである [64]。概略図を図 38 に
示す [64]。CLAT を機器として導入するのではなく，Android OS の 1 つのデーモ
ンとして扱い，モバイルオペレータの提供する IPv6 only 網を超えて PLAT との
通信を行うものである。2012 年時点では，特定の端末に対して12 ，T-Mobile USA
および Verizon Wireless の携帯電話ネットワークでサポートされている。
12
Nexus S, Galaxy Nexus, Galaxy S2, Galaxy S3, Galaxy Note 2, and all Verizon Wireless
LTE phones
51
図 38 Android CLAT の流れ
4.2.2 T-Mobile USA
T-Mobile USA では，IPv4 アドレス枯渇の対策として，IPv6 を携帯電話網内
へ取り入れ IPv6 only ネットワークを作っている。その中で，IPv4 ネットワー
クへアクセスするための手段としてベータトライアルで NAT64/DNS64 および，
464XLAT を導入している [65, 66]。実際に Nexus S を使用して Android CLAT に
て UMTS IPv6-only network with DNS64/NAT64 を利用した結果を図 39 に示す
[66]。
図 39 (a) ではインターフェース rmnet0 に，CLAT インターフェイスおよび
IPv6-only インターフェイスとして，それぞれプライベート IPv4 アドレスおよび
IPv6 アドレスが付与されていることがわかる。また，図 39 (b) より，IPv4 側
IPv6 側共に，外部との疎通性があることが確認されている。
4.2.3 China Mobile
China Mobile では，図 40 のように 8 つの省で固定回線，Wi-Fi アクセスポイ
ント，モバイル回線においてそれぞれ IPv6 の試用運営を行っている [67]。固定回
52
(a) 割り当てられた IPv6 アドレス
(b) 疎通性の確認
図 39 Android CLAT による IPv6 セルラーネットワーク
線ではデュアルスタック回線および，IPv4/IPv6 移行・共存技術として NAT64 と
DS-Lite を用いた回線を提供している。Wi-Fi アクセスポイントでは，デュアル
スタック回線を，モバイル回線ではデュアルスタック回線および，IPv4/IPv6 移
行・共存技術として NAT64 を用いた回線を提供している。
4.3 IPv6 移行関連技術の運用により得られた知見
本節では，IPv6 移行関連技術を利用してネットワーク運用を行い報告された知
見について述べる。
53
図 40 China Mobile におけるモバイル用 IPv6 トライアルネットワーク
4.3.1 T-Mobile USA での知見
T-Mobile USA による NAT64/DNS64 を用いたネットワークでは，Web や Email
と言ったサービスは問題無く動き，おおよそ 85%の Android アプリケーションは
動き，Symbian 市場においても同様の結果が得られたと報告されている。しかし
ながら，Skype や MSN などの IPv4 アドレス構造を参照して P2P 通信を行うア
プリでは，NAT64/DNS64 経由では通信できないことがわかった [28, 29, 51, 65]。
特に，Skype に関しては，464XLAT を経由してもうまく通信が行えないことが
指摘されていたが [51]，2013 年 11 月に公開されたパッチによりこの問題は解決
し，現在は 464XLAT 経由での使用が可能となっている [51, 52]。なお，その他の
NAT64/DNS64 経由では通信できなかったアプリケーションやサービスについて
も，464XLAT 経由では問題無く通信をできていることが報告されている [65]。
また，Android スマートフォンに対して IPv6 疎通性を持たせたモバイル環境を
構築してから現在までで，実に 27%ものトラフィックをネイティブ IPv6 にするこ
とに置き換えることができた [58]。これらは，表 10 に示した通り，ユーザーが利
54
用している主要サービスの IPv6 への対応状況によっても異なる [68]。そのため，
これらサービス提供側が IPv6 を有効にすればより IPv6 利用率は上がるものと言
える。
表 10 主要サービスの IPv6 対応状況
利用頻度
Web サイト
IPv6 対応
1
google.com
OK
2
facebook.com
OK
3
youtube.com
OK
4
yahoo.com
OK
5
amazon.com
NOT OK
6
linkedin.com
NOT OK
7
wikipedia.org
OK
8
ebay.com
NOT OK
9
twitter.com
NOT OK
10
bing.com
NOT OK
4.3.2 Arkko らによる知見
Arkko らは IPv6 only Network として，IPv4 ルーティングと DHCPv4 サーバ
を利用せずに，NAT64/DNS64 を利用して IPv4 インターネットとの疎通性を確
立した IPv6 ネットワークを構築した [28]。
この中で，Linux, Mac OS X 10.6 (Snow Leopard), Windows 7, Android OS が
動作しているマシンでネットワークの利用を検証した結果をそれぞれ，表 11 と
表 12 に示す。表 11 に示した通り，インスタントメッセンジャーなどの音声系ア
プリは，Web で提供されているもの以外はほとんどが利用できないという結果で
あった。パケットトレースを行った結果，プロトコルが IPv4 アドレスリテラル
表記で通信しようとしており，これが動作しない原因であると考えられている。
また，Google Talk client に関しては，IPv6 接続がソフトウェアからサポートさ
55
表 11 IPv6 only Network におけるインスタントメッセンジャーの動作状況
ソフトウェア
動作
Facebook on the Web (http)
OK
Facebook via a client (xmpp)
OK
Jabber.org chat service (http)
OK
Gmail chat on the web (http)
OK
Gmail chat via a client (xmpp)
OK
Google Talk client
NOT OK
AIM (AOL)
NOT OK
ICQ (AOL)
NOT OK
Skype
NOT OK
MSN
NOT OK
WebEx
NOT OK
Sametime
OK (NOW)
れていなかった。Sametime に関しては，動作しなかったものの，実験中にソフ
トウェアのアップデートを適用すると，IPv6 での疎通性が確認できた。
表 12 に示した通り，ゲームにおいても同様で Web で提供されているゲーム以
外の通信機能は IPv6 only Network からは使用できなかった。Web ゲームにおい
ても Runescape に関しては，こちらも先と同様で，IPv4 アドレスリテラル表記
によりアドレス解決できないという状況に陥った。
ほとんどのゲームは，ネットワークへの接続ができず，結論として使用されて
いるネットワークコードの API が古いため，IPv6 による接続ができなかったも
のと考えられている。
その他のアプリケーションとして，音楽サービスでは Spotify が，アプライア
ンスとしてはネットワークインターフェースを有する Web カメラへの接続や一
部ファイアウォールに難が生じた。また，先ほどから述べている通り，DNS64 の
性質上，IPv4 アドレスリテラル表記への通信が行えず，Alexa のリストによると
56
表 12 IPv6 only Network におけるゲームの動作状況
ソフトウェア
動作
Web-based (e.g., armorgames)
OK
Runescape (on the web)
NOT OK
Flat out 2
NOT OK
Battlefield
NOT OK
Secondlife
NOT OK
Guild Wars
NOT OK
Age of Empires
NOT OK
Star Wars: Empire at War
NOT OK
Crysis
NOT OK
Load of the Rings: Conquest
NOT OK
Rome Total War
NOT OK
Load of the Rings: Battle for Middle Earth 2 OK (NOW)
10,000 Top サイトのうち約 2% のサイトが IPv4 アドレスリテラル表記であるこ
とも分かった。
4.3.3 櫨山らによる知見
櫨山らは WIDE Project における研究会である WIDE Camp を利用して，IPv6
only Network 実験を行っている [29, 69, 30, 70]。表 13 に示した通り，IPv6 only
Network 実験として，それぞれ，4rd, 464XLAT, SA46T, NAT64/DNS64 を用い
て検証している。
1 回目の実験では，WIDE バックボーンと会場間を L2TP トンネル接続で結び，
IPv6 接続性を得た。その上で，4rd, SA46T や NAT64/DNS64 を適用し，IPv6
ネットワーク越しで IPv4 接続性を提供した。ネットワークユーザである合宿参
加者には無線接続でネットワークを利用させた。
2 回目の実験では，従来通り WIDE バックボーンと会場間を L2TP トンネル接
57
表 13 WIDE Camp における IPv6 実験状況
時期
IPv6 提供方法
2011 年秋 RA (address prefix, router),
IPv6 接続方法
IPv4 接続方法
IPv6 over L2TP
4rd, SA46T,
DHCPv6 (DNS)
2012 年春 RA (address prefix, router),
NAT64/DNS64
NGNv6 (IPoE, PPPoE),
4rd, 464XLAT,
IPv6 over L2TP
SA46T, NAT64/DNS64
NGNv6 (IPoE),
SA46T-AT,
IPv6 over L2TP
NAT64/DNS64
DHCPv6 (DNS)
2012 年秋 RA (address prefix, router),
DHCPv6 (DNS)
続で結ぶ方法と，NTT 西日本が提供する NGNv6 サービスを利用し，IPv6 アクセ
スネットワーク 2 種類（IPoE および PPPoE）による IPv6 接続性を確保し，IPv6
の複数ネットワーク環境を構築した。さらに，IPv4 ネットワークへのアクセス手
段も 464XLAT を加え，4 種類の技術を時間毎に切り替え，各技術を利用できる
ようにした。
3 回目の実験では，2 回目の追調査として，各端末での動向に絞った調査を実施
した。NAT64/DNS64 を用いた IPv6 only ベースの構成と SA46T を用いた構成の
2 種類を用意した。ここでは，Microsoft Windows, Mac OS X, iOS, Android OS
についての評価を掘り下げて行い，端末へのネットワーク接続情報の通知方法の
検討およびその対策についての効果測定および，利用できないアプリケーション
に関する具体的な種別の特定を行った。
これらの検証でも，端末依存の問題，環境依存の問題，アプリケーション依存
の問題が報告されていた。
まず，端末依存問題については表 14 に結果を示す。こちらでは各 OS 毎の DHCPv6
の動作状況と，IPv4 リンクローカルアドレス [71] が付与された場合の IPv6 アド
レス自動設定が機能するかについてを示している。
今回櫨山らが実験したネットワークでは，DNS64/NAT64 を用いていた。詳し
い実験環境は表 13 の通りであるが，DNS64/NAT64 環境において DNS64 サーバ
58
表 14 OS による IPv6 アドレス自動設定機構の稼働状況
169.254 の影響
OS
Version
RA
DHCPv6
Windows
XP
○
×
Vista
○
○
7
○
○
8
○
○
10.6 (Snow Leopard)
○
×
10.7 (Lion)
○
○
10.8 (Mountain Lion)
○
○
1.6.x (Donut)
×
×
×
2.3.x (Gingerbread)
○
×
×
4.0.x (Ice Cream Sandwich)
○
×
×
4.1.x (Jelly Bean)
○
×
×
5
○
○
6
○
○
4 JB
○
×
×
5
○
×
×
Kindle
3.3
×
×
NetBSD
5.1
○
×
6.99.4
○
×
12.04
○
○
Mac OS X
Android
iOS (iPad)
iOS (others)
Ubuntu
59
の指定に DHCPv6 を利用していた。DHCPv6 は，2.2 節の表 3 で述べた通り，こ
の機能が標準で実装されている OS は比較的最近のバージョンに限られる。そのた
め，古い OS については手動で DNS サーバを指定する必要が生じた。また，IPv6
only 環境では，IPv4 アドレスの提供を行っていなかったため，自己解決アドレス
が付与される。IPv4 アドレスに自己解決アドレスが付与されると，IPv6 アドレ
スの自動設定が行われない端末も存在した。当該端末では，グローバル IPv4 ア
ドレスもしくは，プライベート IPv4 アドレスが付与されると，IPv6 アドレスを
自動設定で取得できることを確認しているため，ベンダー側から IPv6 単体での
利用を想定されていないと言える。
2 回目の実験では，時間毎に無線 AP を切り替え，各種移行技術を利用すると
いう性質上，端末によっては，ネットワーク切り替え時に以前に取得したネーム
サーバ情報を保持し続け，名前解決ができないケースがあった。
一般には，各種移行技術を使い比べることは想定されていないが，端末の移動
に伴う IPv4 and IPv6 Native ネットワークと IPv6 only ネットワークとの切り替
えは十分に考えられるので，本件も重要な課題と言える。
表 15 モバイル端末での IPv6 周辺の UI 対応状況
OS
Version
UI（表示）
UI（設定）
Android
2.3.x (Gingerbread)
×
×
iOS
5
×
×
iOS (iPad)
5
×
×
次に，モバイル端末におけるユーザインターフェース周りの問題を表 15 に示
す。基本的にモバイル端末の OS では，IPv6 アドレス自動設定機構が問題無く
動作し，IPv6 only ネットワークに接続できているもののその状態をユーザーイ
ンターフェースから確認できない OS がある。そのため，多くのモバイル端末は
IPv6 スタックの実装は行われているが，ユーザーインターフェースは IPv4 依存
のまま残されているという状況である。Wi-Fi 設定情報や IP アドレス情報を確認
すると，IPv4 に関する情報は表示されるが，IPv6 に関する情報は得られないた
60
め，ブラウザなどの通信機能を有するアプリを立ち上げ，通信できれば IPv6 は
動くという判断が行われた。
なお，モバイル端末の場合，IPv6 アドレス自動設定が動作せず，かつユーザー
インターフェースでの設定ができないものに関しては IPv6 only ネットワークに
は接続できないということになる。
また，アプリケーションに関する問題としては，Skype をはじめとする音声系
アプリケーションや VPN アプリケーションが挙げられていた。音声系アプリケー
ションは Arkko らも指摘していたが，それ自体にシグナリングや端末間ルーティ
ングの仕組みなど，システム全体を通した管理プロトコルを備えている事があり，
その一部が IPv4 アドレスと密接に関係しているようであると報告されている。
特に Skype などは，単一のクライアントアプリケーションとしての対応の他に，
スーパーノードなどシステム全体としての対応が必要になることが考えられる。
今，IPv6 対応がなされていないアプリケーションは，アドレスファミリに依存
しないプログラムコードに書き換える前に，デュアルスタック化によるセキュリ
ティ上の問題（踏み台や意図しないプロトコル中継など）への懸念から，何をど
こまで対応させるべきかの検討が必要であり，簡単に対応はできない事が述べら
れている。
その他に，CVSNT や NOD32 と言ったウイルス対策ソフトの定義アップデー
トが行えなかったり，Mac 版 MS Office のアップデートができないという報告が
あった。
また，HTTP ベースのアプリケーションの多くは NAT64/DNS64 を用いた IPv6
only ネットワークで問題無く動作するが，一部 Dropbox（オンラインストレージ）
や Tween（Twitter クライアント）などで，特定の処理だけ実行できないものが
発見された。こちらに関しては追調査が必要と述べられているが，IPv4 アドレス
のハードコーディング，IP アドレスベースのクッキーや認証関連での問題が要因
の可能性が高いと述べられている。
更に運用に関して得られた知見として，IPv6 only ネットワークに接続できな
い端末の状況が以下の様に述べられていた。
61
1. 端末に IPv6 のネームサーバ情報が自動登録されないため，手動設定を
行う必要がある
2. ユーザインターフェースが IPv6 へ対応していないため，静的設定が投
入できない
3. IPv6 のネームサーバ情報が設定できないため，名前解決ができない
4. IPv4 の自己解決アドレス取得のため IPv6 通信が定期的にリセットされ
てしまう
これらの状況を回避するために，以下の設定を行うことで，iOS や Android の
搭載された端末においても，IPv6 only ネットワークへの接続が可能となったこ
とが述べられている。
1. NAT64/DNS64 の利用
2. DHCPv6 による DNS (IPv6) の設定
3. DHCPv4 によるプライベート IPv4 の設定
4. DHCPv4 による DNS (IPv4) とデフォルトルータの応答設定（指定し
たルータは実際にはフォワードしない）
5. DNS (IPv4) は IPv4 ローカルネット上に配置
6. DNS (IPv4, IPv6) で”A”フィルターを実装
7. 全ての”A”に NODATA を返答
8. ”AAAA”はそのまま上流の DNS64 に転送
62
図 41 Cisco におけるネットワーク構成
4.3.4 Cisco における知見
ネットワーク機器ベンダーである Cisco Systems は，図 41 のように MAP-T
を利用した構成においても，Web や Mail，YouTube などのビデオコンテンツや
FTP によるアップロードサービスが何不自由なく使える事を示している [72]。
4.3.5 JANOG31 会場ネットワークにおける知見
日本のインターネット技術者、および、利用者が参加し，インターネットに於け
る技術的事項，および，それにまつわるオペレーションに関する事項を議論，検
討，紹介する場所として Japan Network Operator Group (JANOG) がある。その
JANOG31 ミーティングにおいて使用された，図 42 に示す JANOG Meeting 本会
議場ネットワークでは，通常のデュアルスタックネットワークの他に「IPv4/IPv6
移行・共存技術」をテーマの 1 つとして，MAP-E, DS-lite, 464XLAT が用意され
た [73]。JANOG31 において使用した参加企業提供の機器について表 16 に示す。
その中でも，MAP-E では BR として IP Infusion のソフトウェア実装をした PC
(BR1) と，古河ネットワークソリューションの FX5000 (BR2) という 2 つの機材
を用意して，BR の切り替え実験が行われた。まず，BR1, BR2 共に上流に繋がっ
63
図 42 JANOG31 におけるネットワーク構成
ている状態から，BR1 の上流への経路を撤去し，BR2 へうまく通信が置き換わ
るかという切り替え実験が行われた。結果として，この試みは成功した。
4.3.6 Interop Tokyo 2013 ShowNet における知見
Interop Tokyo におけるデモンストレーションネットワークである ShowNet で
は過去にも各種 IPv4/IPv6 共存技術の検証を行っていた。2013 年には，今までの
トライアルレベルから商用品質レベルでの提供を目標とし，IPv4 over IPv6 技術
の導入を行った。Interop Tokyo 2013 ShowNet において使用した参加企業提供の
機器について表 17 に示す [74]。
464XLAT, DS-Lite については，バックボーン側機器 (PLAT, AFTR) とユー
ザ側機器 (CLAT, B4) に関して複数のメーカから提供されたため，全ての組み合
64
表 16 JANOG31 にて使用した機器
提供社名
製品名
用途
IP Infusion
PC ルータ
MAP-E BR
古河ネットワークソリューション
FX5000
MAP-E BR
古河ネットワークソリューション
F60/F200
MAP-E CE
銀座堂
ASAMAP
MAP-E CE
ヤマハ
RTX1200
MAP-E CE
A10 ネットワークス
AX2500
DS-Lite AFTR, 464XLAT PLAT
インターネットイニシアティブ
SEIL/X1
MAP-E CE, DS-Lite B4
ジュニパーネットワークス
SRX5600
464XLAT PLAT, NAT64
NEC アクセステクニカ
RG-A54i
DS-Lite AFTR
NEC アクセステクニカ
CL-AT1000P
464XLAT CLAT
表 17 Interop Tokyo 2013 ShowNet にて使用した機器
提供社名
製品名
用途
シスコシステムズ
ASR9000
MAP-E BR
インターネットイニシアティブ
SEIL/x86
MAP-E CE, DS-Lite B4
古河電工
FX5000
MAP-E BR
A10 ネットワークス
AX5630
MAP-E BR
セイコーソリューションズ
iX-3740
MAP-E CE, DS-Lite B4
ジュニパーネットワークス
SRX5600
464XLAT PLAT, NAT64
NEC アクセステクニカ
Aterm
DS-Lite AFTR, 464XLAT PLAT
Infoblox
Trinzic 820/vNIOS
DNS64, DS-Lite B4, 464XLAT CLAT
富士通
SA46T/SA46T-PR/SA46T-PT
65
表 18 Interop Tokyo 2013 ShowNet にて使用した MAP-E パラメータ
パラメータ
値
Rule IPv6 prefix
2001:3e8:6000::/56
Rule IPv4 prefix
130.129.255.92/30
End-user IPv6 prefix
2001:3e8:6000:00xx::/64
EA bits
8bits (64-56)
Port-Set ID
6bits (8-2)
PSID offset
4
ports/user
960ports
BA Addresses
2001:3e8:0:2900::1/128
わせを実現できるように実装された。
MAP-E については，ASR9000 と FX5000 の 2 台の BR を IP Anycast を用いた
負荷分散，冗長構成とした。MAP-E ではバックボーン側機器をステートレスにす
ることができるため，このような一般的なルーティングの技術を用いて負荷分散，
冗長構成を実現出来る。なお，MAP-E のパラメータは表 18 の通りである [74]。
これらの移行技術を用いた環境において，文献 [74] では以下の項目について確
認を行った。
MTU の正常性
設定した MTU サイズまでのパケットで通信が行えるかを確認。
TCP や UDP パケットの疎通
TCP については SYN パケットの中の MSS 値が正しく CE で調整されてい
るかについても確認。
ICMP パケットの疎通
Echo Request/Reply, Time Exceed, Fragment Needed, Host Unreachable
の 4 種類にて確認。
66
フラグメントパケットの疎通
分割された IP パケットをユーザ側機器、バックボーン側機器共に正しくハ
ンドリングできるかを確認。
主要な Web サイトの閲覧
ユーザが利用すると考えられる主要な Web サイトをブラウザで閲覧し，遅
延やコンテンツの欠損の有無を確認。
P2P 系アプリケーションの動作
Skype などのクライアント端末間で直接通信するアプリケーションは，CE
の NAT の実装に強く依存するため、音声やビデオが疎通するか確認。
MAP-E における異ドラフトによる実装
MAP-E では参照ドラフトによって 2 種類の実装があるため両方で確認。
これらを確認した結果，以下に示すいくつかの設定・調整を行っておれば，本
会期でのトラブルは全く無く，ユーザからの不具合報告も無かった。
また，MAP-E は本論文執筆時においても IETF draft となっており，改訂の度
に数回の仕様改定が行われている。2014 年 4 月時点でのリビジョンは-10 である。
最新ドラフトでの相互接続検証で問題となった箇所はリビジョン-03 から-04 への
アップデートとして，カプセル化した際の IPv6 パケットに付与する IPv6 アドレ
スのインターフェース ID が変更となった。
変更点を以下に示す。
古いフォーマット (-03)
+--+---+---+---+---+---+---+---+---+
|PL|
8
16
24
32
40
48
56
|
+--+---+---+---+---+---+---+---+---+
|64| u | IPv4 address
|
PSID | 0 |
+--+---+---+---+---+---+---+---+---+
67
新しいフォーマット (-04)
|
128-n-o-s bits
| 16 bits|
32 bits
|
| 16 bits|
+--------+----------------+--------+
|
0
|
IPv4 address
|
PSID
|
+--------+----+-----------+--------+
多くのメーカーは古いフォーマット (-03) で実装を進めており，本会期中に提
供するフォーマットは-03 に統一した。
しかし，新しいフォーマット (-04) をサポートしている機器もあったため，対応
機器のメーカに協力を仰ぎ，Hotstage 期間中に相互接続検証を行った。あるメー
カーにおいて，ICMP パケットの新フォーマットによるカプセル化が未対応であっ
たが，TCP/UDP のパケットについては，問題無く接続できた。図に示すパケッ
トダンプにおいて，新フォーマットでのアドレスマッピングが行われていること
が確認出来る。
19:12:49.571434 2001:3e8:6000:c0:0:8281:ff5f:0 > 2001:3e8:0:2900
::1: IP 130.129.255.95.45089 > 133.242.53.30.80: S 1937843878:19
37843878(0) win 14600 <mss 1420, sackOK,timestamp 344073592 0,no
p,wscale 6>
結果として，相互接続性の問題は無く，非常に良好に動作したと報告されてい
る [74]。
• MTU の問題
IPv4 における Path MTU Discovery Blackhole による通信不良を避けるた
め，CPE にて IPv4/TCP SYN パケットの MSS 値の調整を行うような設定
を行った。具体的な値は以下の式で与えられる。
TCP MSS 値 = IPv6 MTU - 40（IPv6 ヘッダ長） - 20（IPv4 ヘッダ長） 20（TCP ヘッダ長）
なお，今回使用した MAP-E 機器の中には，IPv6 ネットワークの Path MTU
68
Discovery Blackhole も避けるため，IPv6 MTU が 1280Bytes 固定設定となっ
ている機器が存在した。そのため，MAP-E ドメインではこの値で統一した。
• 機器により扱いが異なるフラグメントの問題
上記問題とも関連するが，サイズの大きい IPv4 パケットを IPv6 でカプセ
ル化する際に，IPv6 フラグメントを用いて転送する機器が存在した。その
際，対向側機器でフラグメントされた ICMP パケットをドロップするよう
な実装があり，ICMP パケットのみ通過できないケースが存在した。
4.3.7 本学クライアントネットワークにおける知見
本学のクライアントネットワークの一部に，NAT64/DNS64 環境を用意し，当
該環境で得られた知見を述べる。本環境では，主に Mac OS X 10.7 (Lion)，Mac
OS X 10.8 (Mountain Lion) および，Windows 7 を利用した。Mac OS X で利用
した限りでは，Web や SSH, Subversion といった CLI アプリケーションは問題無
く利用できた。メールに関しては，Mozilla Thunderbird を利用したが，メール
サーバが IPv6 対応であれば，即座にメールが送れたが，メールサーバが IPv4 に
しか対応していない場合では，送受信を行う際に，30 秒ほどの遅延が発生した。
Windows においてもほぼ同様の結果となったが，Subversion クライアントである
TortoiseSVN は利用できなかった。
モバイル端末では，iOS 6, iOS 7 および，Android 4.2.x (Jelly Bean) を利用し
た。それぞれ図 43 に iOS 7 におけるユーザインターフェースと，図 44 に Android
におけるユーザインターフェースを示す。
それぞれのネットワークインターフェースについている IPv4 アドレスは確認
出来るが，IPv6 アドレスにについては確認出来なかった。また，Web やメール，
Facebook，Twitter といったアプリケーションは問題無く通信できたが，iPod touch
(iOS 6.1.3) 上の Polycom RealPresence App では，通信ができなかった。こちら
は同アプリにおける IPv6 関連の設定が存在しなかったため，同アプリが IPv6 非
対応であると考えられる。
69
図 43 iOS 7 におけるユーザインターフェース
70
図 44 Android 4.2.x (Jelly Bean) におけるユーザインターフェース
71
5. IPv4 Sunset に向けて
本章では，4 章の実情を踏まえて，まず，IPv4 Sunset を行うにあたって，IPv4
を残さなくてはならない場所，IPv4 を残した方が好ましい場所，IPv4 を残さな
くとも問題のない場所に分けて整理する必要がある。
それぞれ，IPv4 を残さなくてはならない場所としては，外部へ公開している
サーバ群である。IPv4 を残した方がいい場所としては，クライアント側ネット
ワークである。IPv4 を残さなくとも問題のない場所としては，プロバイダーコア
ネットワーク，エンタープライズネットワーク，データセンターネットワークな
どの，人が常用しない内部ネットワークが挙げられる。
5.1 モバイルオペレータの場合
モバイルオペレータの場合，T-Mobile USA や China Mobile などのように実際
に，IPv6 を携帯電話網内へ取り入れ IPv6 only ネットワークを作っている。その
中で，IPv4 ネットワークへアクセスするための手段としてベータトライアルで
NAT64/DNS64 および，464XLAT を導入している [65, 66, 67]。
一般の商用 ISP もモバイルオペレータも顧客に対してインターネット接続性
を提供する事業者であることに変わりは無いが，モバイル向けネットワークがコ
ンピュータ向けネットワークと決定的に違うのは，通常，モバイル端末側で何か
サービスを提供していることが無いということにある。何らかのサービスを提供
する必要があるならば，グローバル IPv4 アドレスが必須となる。そのため，コン
ピュータ向けの ISP では基本的にグローバル IPv4 アドレスの払い出しを行って
いる上，払い出す IPv4 アドレスを恒久的なものとする固定 IP アドレス配布サー
ビスも行っている。
そのような中，モバイルキャリア各社からモバイル端末向けに提供されている
IPv4 アドレスは，グローバルアドレスからプライベートアドレスへと変化してき
ている。また，CGN 配下のプライベート IPv4 アドレスを配布するオペレータも
存在し，モバイル環境におけるグローバル IPv4 アドレスはよりユーザから遠の
くものとなっている [11]。このような環境において，モバイル端末 1 つずつに対
72
するグローバル IPv4 アドレスの必要性は減りつつある。国内においても，IPv6
+ プライベート IPv4 アドレスの組み合わせでモバイル端末へ IP アドレスを提
供しているキャリアも存在することから，今後はより，モバイル環境におけるグ
ローバル IPv4 アドレスの削減が期待できる。
しかしながら，近年ではモバイル環境においても，スマートフォンの登場によ
りパケット通信網を超えた通話やメッセージ通信などの需要が高まっている。こ
のような中で，IPv6 一本化を行うと，Skype などの P2P 通信を行うアプリによ
る通話やメッセージ通信ができないものとなる [30, 65]。
ただし，ユーザ側端末において常時起動しているアプリケーションなど多数の
アプリケーションが常時インターネットアクセスを必要としており，各端末が必
要とする NAT セッションも膨大な数に膨れあがる。コンピュータの場合では，1
ユーザに必要な NAT セッションは 1000∼2000 程度であることが報告されている
[75]。また，コンピュータの場合と異なり常時起動しているモバイル端末ではア
クティブ率にも違いが出てくると考えられる。そのため，NAT による IPv4 アド
レス利用数の削減にも限界が予想できる。
そこで，ユーザ側（モバイル端末）においても IPv4 を併用して利用する 464 技
術は重要なものとなってくる。ただし，モバイルネットワークでは DHCP を使
わないため，単純に MAP や DS-Lite を組み合わせた 464 ネットワークを構築す
ることはできない [68]。また，MAP のようなステートレス型では，各 MAP 領域
に多数の IPv4 アドレスを要するため，IPv4 アドレス削減の観点から好ましくな
い。その上，モバイル環境ではコンピュータ向けネットワークとはやりとりされ
るデータ量の違いもあり，よりトランスレータを用いた構成がとりやすいものと
考えられる。
5.2 キャンパスネットワークの場合
キャンパスネットワークは，古くからインターネットを利用しており IPv4 ア
ドレスを潤沢に保有している場合と，近年新しく開校・開学したため少ない IPv4
アドレスでネットワークを運用している場合について述べる。
73
キャンパスネットワークでは，一般企業と異なり，学生や教員が使用する端末
は持ち込みが許可されている。そのため，ハードウェアや OS も多種多様となり，
管理が煩雑となる。また，本学では十分な数のグローバル IPv4 アドレスを有して
いるため，各研究室向けのセグメントにて公開サーバを設置し，学内ネットワー
ク上の色々な場所で，学外向けのサービスを提供しているため，単純に学外から
のトラフィックを遮断することができないという問題がある。また，インシデン
ト発生時において，各サーバの管理者への連絡が遅れるということもある。
5.2.1 国立高専の事例
従来，国立高等専門学校（国立高専）では，各校が歴史的 PI アドレスの保有・
管理あるいは，歴史的 PI アドレス，IP アドレスを有しない国立高専では，外部
への委託という形でネットワーク運用を行っていた。現在は表 19 に示した通り，
計 35 校の国立高専が/24 以上の歴史的 PI アドレスを保有している [76]。
1.1 節で述べた通り，歴史的 PI アドレスへの課金が 2012 年度から始まってい
る。この課金はブロック単位では無く，IP アドレスの保有総数によって課金され
ることになっており，IP アドレス保有量が多ければその分，1IP アドレスあたり
の課金単価が下がることになる [7]。2004 年 4 月 1 日に全国の国立高専が，独立
行政法人国立高等専門学校機構（高専機構）1 法人に集約された。このことに伴
い，歴史的 PI アドレスの管理費を下げるため，全国立高専の IP アドレス管理者
を高専機構に集約した。
集約目的は，管理予算削減のみならず，ネットワーク資源が不十分な高専への
融通などを想定している。特に，現時点では，ネットワーク資源が不十分な国立高
専では，高専機構内の双方向通信を実現する VPN 網を構築できないため，VPN
専用回線を別途契約している状態である [76]。現在，国立高専は 51 校（55 キャン
パス）あり [77]，これらのアドレスを 55 キャンパスで融通することを考えると，
1 キャンパスあたり 7,800 以上の IP アドレスを有することができる。実際には，
現在使用されているアドレス数の確保や IP ルーティングの仕組みを考慮してい
ないため，全くもって現実的ではない。特に，使用していないアドレスブロック
を集めるため，アドレス集約をし，アドレス配分を行うコストより，新規に高専
74
表 19 国立高専が保有している歴史的 PI アドレスのアドレスブロック数
ネットワークアドレス
（アドレス数の端数は切り捨て）
学校数
/16
6
/19
1
/20
1
/21
3
/22
15
/23
6
/24
3
計
35
機構として IPv6 を導入し，高専機構との連絡回線を設けた方が，後々の維持費
を考慮すると安価になると考えられる。
5.3 グローバル IPv4 アドレスをベースとした構成
国立大学などは，歴史的 PI アドレスと言われる IP アドレスを潤沢に保有して
いる場合がある。この場合，キャンパスネットワーク全体をグローバル IP アド
レスを用いて構成していることが多い。
しかし近年では，はじめに述べた通り，歴史的 PI アドレスに対する課金を理
由に，IPv4 アドレスの返却・移転を行っている大学も登場している [78]。
弓削商船高等専門学校の場合では，キャンパス内部はプライベート IPv4 アド
レスへの変更を見据えて，グローバル IPv4 アドレスによる運用体系から IPv6 へ
の運用体系に変更を行うなどの事例 [42] もあるが，依然として多くの大学ではグ
ローバル IPv4 アドレスを保有・提供し続けている。
75
表 20 本学でのアドレスブロックの利用状況
現状の
提案構成の
/24 アドレス
/24 アドレス
ブロックの数
ブロックの数
ルータ間
8
1
外部公開用サーバ
5
4
VPN サーバ&クライアント
1
2
学内サーバ&クライアント
145
0
Reserved
97
248
用途
5.3.1 NAIST における一例
表 20 に示した通り，現在，本学では 5 つの/24 アドレスブロックを外部公開用
サーバに用いている。また，その他のアドレスブロックから学外に公開している
サーバが 194 台あり，これらのサーバにグローバル IPv4 アドレスをダイレクト
に提供することや NAT46 を介して提供することを考慮しても，公開サーバ用に
おおよそ 1 個の/24 アドレスブロックが必要となる。現状，5 個の/24 アドレスブ
ロックについてもある程度の未使用アドレスが存在するため，そのまま 5 個の/24
アドレスブロックを公開サーバ用に確保しておくと問題ないと言える。
5.3.2 NAIST における IPv4 通信の内訳
本学には，曼陀羅ネットワークと呼ばれている学内ネットワークがあり，プレ
フィクス/16 の IPv4 グローバルアドレスおよび，プレフィクス/48 の IPv6 グロー
バルアドレスが与えられている。曼陀羅ネットワークの概略図を図 45 に示す。
現時点での曼陀羅ネットワークは，ほぼ IPv4 のみで運用されており，一部の
基幹ネットワークおよび，サーバや，研究・実験等において IPv6 が運用されて
いるだけであって，全体的な IPv6 化は進んでいない状況である。そのため，ト
ラフィックを IPv6 に集約するにあたって問題がないかどうかを，現在の本学のト
ラフィックから判断することとする。
76
Internet
firewall
DMZ
core L3
server
core L3
floor
Switch
floor
Switch
core L3
core L3
floor
Switch
floor
Switch
図 45 曼陀羅ネットワーク概略図
図 45 で示した図のうち，各棟の集約スイッチでは，各階からのトラフィック
を，ルータからは DMZ へのトラフィックをそれぞれ sFlow を用いてサンプリン
グしており，このデータを学内トラフィックの内訳とする（図中の紫色の点線で
示した矢印のポイントで集計している）。
表 21 に，平日 1 日（2013 年 11 月 1 日）のトラフィックの様子を載せる。それぞ
れ，IPv4 と IPv6 における，プライベートアドレス・リンクローカルアドレス同士
の通信，学内同士の通信，学内と学外の通信の比率である。なお，全サンプリング
フロー数は 4, 133, 410 であり，サンプリング間隔は 1/2048 である。また，全学で
の IPv4 と IPv6 の比率は IPv4 : IPv6 = 99.58% : 0.42% となっている。DMZ とそ
の他のセグメントとの通信比率は IPv4 の場合，DMZ : その他 = 2.27% : 97.73%
であり，IPv6 の場合は DMZ : その他 = 2.28% : 97.72% である。
77
表 21 本学における平日 1 日のデータ
DMZ
その他
Private / Link local
学内
学外
IPv4
0.00%
34.47%
65.53%
IPv6
44.86%
0.00%
55.14%
IPv4
2.27%
82.47%
15.26%
IPv6
7.58%
43.70%
48.72%
表 21 では，IPv4 と IPv6 でのトラフィックの学内・学外比に大きく差が出た
が，これは，本学のネットワークにおいて IPv6 が部分的にしか導入されていな
い事に起因していると考えられる。よって，全学で IPv6 化を行えば，IPv4 と同
様，多くのトラフィックが学内で完結すると考えられる。
ISP のネットワークと比較して考えると，近年のインターネットはかつての Tier1 を頂点とした教科書モデルとは異なり，Akamai, Facebook, Google, Microsoft,
YouTube などの”Hyper Giants”と呼ばれるコンテンツ保持者へと，トラフィック
が流れている [61]。言い換えれば，自 AS で完結するトラフィックより，他 AS へ
流れるトラフィックが多いということである。
文献 [77, 79] のように学内向けサービスを外部委託してしまうとこの限りでは
ないが，学内向けサービスを内部で提供している場合には，導入機器が IPv6 に
対応している限りでは一般の ISP より IPv6 化への障壁は少ないと考えられる。
5.4 プライベート IPv4 アドレスをベースとしたエンタープライズ
ネットワークの場合
今日において，クライアントにはプライベート IPv4 アドレスを割り当て，NAT44
や Proxy を経由してインターネットへの疎通性を確保する方法が企業等では，一
般的なものとなっている。
このようなネットワーク構成では，既に IPv4 アドレスの利用は最小限に抑え
られており，現状より多くのグローバル IPv4 アドレスの削減は望むことはでき
78
ないと考えられる。
しかし，相手方ホストが IPv6 に対応している場合は，直接 IPv6 による通信
が行うことができ NAT44 テーブルエントリの削減につながる。また，NAT44 に
よる IPv4 通信の削減具合や削減内容を確認し，従来 IPv6 では通信できなかった
ものが，IPv6 への移行できるといった目測が立てやすくなる。更に，NAT44 や
Proxy を導入しているネットワークでは，特定のサイトやポート以外とは通信断
を行うなどの限定的な利用を強いている場合もある。このようなネットワークに
おいては，NAT64/DNS64 の組み合わせだけで，容易に既存のネットワークを置
き換えることができる可能性も考えられる。
79
6. 考察
IPv4 のアドレス枯渇が現実のものとなり，今後は，インターネットを IPv4 ア
ドレスだけでやりくりせねばならないとなると，IPv4 アドレスの移転・売買に伴
う膨大なコストと，組織内におけるネットワーク構成の変更，ルーティングテー
ブルの書き換えといったことを避けては通れないことになる。近年発売されてい
るネットワーク機器やコンピュータなど IPv6 への対応は進んでおり，ますます
IPv6 への移行は現実的な解になりつつあると言える。
現在，ほぼすべての通信事業者のネットワークにおいてコアネットワークは大
幅に進化し，デュアルスタック対応となっている。つまり，エンドユーザやコンテ
ンツオーナから送信されたネイティブ IPv6 トラフィックまたは IPv4 トラフィッ
クは，変換やトンネリングを介することなく，コアネットワークを通過すること
ができる。
しかし通信事業者のネットワークエッジで導入された機器と，サービスプロバ
イダがどこまで IPv6 対応を進めているかに応じて状況が変わる。多くの場合は，
通信事業者とエンドユーザのアクセス設備で利用できる機能によって左右される。
エンドユーザ側またはアクセス設備のいずれかでシングルスタックが採用されて
いる場合，NAT などの変換技術か 6to4 などのトンネリング技術が使用しなけれ
ば両プロトコルの通信は実現出来ない。
IPv6 の導入から数年が経過した現在，サービスプロバイダは IPv6 専用のシン
グルスタックアーキテクチャへの移行を開始している。しかし，既存の IPv4 通信
はエンドユーザやコンテンツプロバイダが引き続き利用するため，このトラフィッ
クもシングルスタック IPv6 ドメインを通過できるようにする必要がある。また，
いずれ IPv6 が主流となり，IPv4 の利用率が徐々に下がり出すと，本格的な IPv4
Sunset に向けた取り組みが実施されると予想される。
IPv4 Sunset という観点から考えると，IPv6 only ネットワークを構築できる
NAT64/DNS64 が，一番 IPv4 アドレスの利用率削減を実現することができる。
しかしながら，本方式では，未だ IPv6 の単体動作という点において完全対応で
きていないモバイル端末やプログラム内部で IPv4 アドレスリテラル表記された
アプリケーションでは，完全に通信できないという欠点を持つ。現時点でのデ
80
バイス・ソフトウェアの実装状況や IPv4 利用者が多数を占めるという状況では，
NAT64/DNS64 によるインターネットアクセス環境を推し進めることは難しいと
言える。
そこで，IPv6 アドレスと同時に NAPT44 化された IPv4 アドレスを提供する
464XLAT, MAP-T, DS-Lite, MAP-E, SA64T と言った 464 技術を利用すること
となる。これらの方式では，IPv4 通信は IPv6 バックボーンを超えるものの，最
終的には IPv4 対 IPv4 の通信となるため，NAT64/DNS64 に比べて，グローバル
IPv4 アドレスの削減は期待できない。しかしながら，バックボーンを完全 IPv6
化し，ユーザ側のスタブネットワークもデュアルスタック化を実現できることで，
バックボーンでの IPv4 アドレスの削減や，来るべき IPv6 への対応を行うことが
可能となる。現在では，モバイルを中心にこのようなネットワークができあがっ
ており，一般ユーザとともにその知見が蓄積されてきている。
特にモバイルやコンシューマ向けの環境では，NAT64/DNS64 に加えて 464XLAT
や DS-Lite を提供しているプロバイダも存在する。T-mobile USA が IPv6 疎通性
を持たせたモバイル環境を構築してから，実に 27%ものトラフィックをネイティ
ブ IPv6 にすることに置き換えることができた。
IPv4/IPv6 移行技術は，年々新たな方式が提案されており，実装や運用を経て
今後も体系の見直し等が必要になることが予想できる。
81
7. おわりに
本課題研究論文では，現実のものとなった IPv4 アドレス在庫枯渇に対し，そ
れに対する解であるインターネット全体の IPv6 化がなされていないことを述べ
た。その結果 IPv6 は今後も普及しない，と結論付けるにはまだまだ早計である
と言える。現在，広く普及している IPv4 だがその起源は 1969 年，米国・国防総
省のネットワークプロジェクト「ARPANET」から始まった。そこから，今日に
至るまでに確固たる地位を築き上げたわけであるが，簡単に決まったわけでは無
く，AppleTalk や NetBEUI など様々なプロトコルの中から時間をかけて多くの人
に IPv4 が選ばれたという結果である。
3 章にて IPv6 の利用を促進するために提案された IPv4/IPv6 移行技術につい
て説明した。IPv4 アドレスの在庫枯渇に加え，これらの技術が導入される事で，
ますます IPv6 が利用しやすい環境が作られていると言える。実際にネットワー
ク機器やクライアント OS においても IPv6 の実装は進んでいる状況である。そ
れぞれ，カプセル化やトランスレート，ステートレスやステートフルという形で
要素で分けられており，大規模 ISP 向け，モバイルオペレータ向けやデータセン
ター向けなど各分野によって採用すべき技術は変わると言える。
4 章においては IPv4/IPv6 移行技術の実運用例および，運用知見をまとめた。
また，5 章では，プロバイダネットワークやエンタープライズネットワークにおけ
る IPv4 Sunset への考え方を述べた。その中でキャンパスネットワークにおける
一例として本学での事例およびトラフィックについても述べた。本学の場合，本
学内で完結するトラフィック，言わば自 AS 内で完結するトラフィック量が多く，
一般の商用 ISP とは異なる結果が得られた。この点からも IPv6 化が進めやすい
と考え，その上で，キャンパスネットワークにおける IPv4 Sunset 手法について
一考した。
IPv4 アドレス在庫枯渇に対しての IPv6 化は，現在，IPv4 アドレスを有してい
る既存ユーザにとっては，旨みの薄い話である。そのため，インターネットショッ
ピングの利用において IPv6 ユーザのみ割引がある，IPv6 を利用すれば IPv4 より
ストレスの無い高速なインターネットが利用できるなどの動きがない限り，早急
に IPv6 が広がると言うことは考えづらい。そのような状況において，IPv4/IPv6
82
両プロトコルの架け橋となる IPv4/IPv6 移行技術は非常に重要な技術である。し
かしながら，IPv4/IPv6 移行技術はまだまだ運用知見が少ないため，実際の端末，
OS，アプリケーションでの動作検証が必要である。今後も各者が協力をし，より
多くのユーザおよびデバイスが自由にインターネットを利用できる環境の構築に
向けて活動すべきであり，今後も研究が期待される分野と言える。
83
謝辞
本課題研究論文の執筆にあたり，本当に多くの方々にお世話になりました。こ
の場をお借りして，お礼を述べさせていただきたいと思います。
まずは，課題研究論文の審査を引き受けてくださいました本学 藤川 和利 教授，
同 山口 英 教授，同 猪俣 敦夫 准教授にお礼を申し上げます。
研究を進めるにあたり，指導教員として研究の場を提供して下さり有益なご助
言ならびに親切なご指導を賜りました，本学 藤川 和利 教授に心より感謝を申し
上げます。
幅広い知見から研究に対するご助言とご指導を頂きました本学 山口 英 教授に
心より感謝を申し上げます。
研究を進めるにあたり，暖かいご激励とご鞭撻ならびに親切なご指導を賜りま
した，本学 猪俣 敦夫 准教授に心より感謝を申し上げます。
また，本課題研究論文の推敲にあたり，有益なご助言ならびに親切なご指導を
賜りました，本学 垣内 正年 助教，同 大平 健司 特任助教に心より感謝を申し上
げます。
研究の方針に関して的確なご指導と熱い励まし，アドバイスを下さいました本
学 門林 雄基 准教授ならびに，東京工業大学 松浦 知史 准教授および，本学 櫨
山 寛章 特任准教授に深い感謝の意を表します。
また，研究の方針から論文の執筆，学生生活に至るまで，数々のご指導と暖かい
励ましを下さいました（独）情報通信研究機構 岡本 慶大 氏，MINES ParisTech
野口 悟 氏，本学 石井 将大 氏に深い感謝の意を表します。
後輩の皆様には，自身の拙い研究発表を聞いて頂き，様々な角度からご指摘を
頂きましたことに感謝の意を表します。
多くのネットワーク設計・運用の場と人脈を築く機会を私に与えてくださいま
した本学 櫨山 寛章 特任准教授，同 垣内 正年 助教，
（独）情報通信研究機構 岡
本 慶大 氏，本学 岡田 和也 氏，
（独）情報通信研究機構 榎本 真俊 氏にお礼を申
し上げます。これらの経験はコンピュータネットワークを基盤とする私の研究活
動において，非常に有意義なものとなりました。
研究活動の息抜きとして，日常生活に関しても食事や珈琲やテニスなど様々な
84
お誘い，ご指導頂きました，東京工業大学 松浦 知史 准教授および，本学 油谷
曉 助教，同 石井 将大 氏にお礼を申し上げます。
さらに，本学での学生生活，研究生活において多大なるご援助を賜り，快適に
研究に励ませて頂きました，秘書の川本 理恵 女史，田村 多佳子 女史および，辻
元 理恵 女史に深く感謝申し上げます。
最後に，共に大学院での学生生活・研究生活を過ごさせていただいた，情報基
盤システム学研究室の皆様，インターネット工学研究室の皆様および，IT-Keys
関係者の皆様，そしてこのような機会を与えてくださったすべての皆様にも深く
感謝申し上げますとともに，これまで育てていただき温かい励ましをいつも送り
続けてくれた家族に心から感謝の意を表し，本課題研究論文を締めくくらせて頂
きます。
85
参考文献
[1] IPv4 アドレスの在庫枯渇に関して - JPNIC, 2011. https://www.nic.ad.
jp/ja/ip/ipv4pool/.
[2] IPv4 Exhaustion — RIPE Network Coordination Centre, 2012. http://
www.ripe.net/internet-coordination/ipv4-exhaustion.
[3] Geoff Huston. IPv4 Address Report, 2014. http://www.potaroo.net/
tools/ipv4/index.html.
[4] Microsoft
pays
Nortel
2011.
$7.5
million
for
IPv4
addresses,
http://www.networkworld.com/community/blog/
microsoft-pays-nortel-75-million-ipv4-address/.
[5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification.
Network Working Group RFC 2460, December 1998. http://www.ietf.
org/rfc/rfc2460.txt.
[6] Campaign:
Day
—
Turn
Deploy360
Off
IPv4
Programme,
on
6
June
December
2014
2013.
for
One
http:
//www.internetsociety.org/deploy360/blog/2013/12/
campaign-turn-off-ipv4-on-6-june-2014-for-one-day/.
[7] 2012 年度 IP アドレス等料金体系改定 - JPNIC, 2012. https://www.nic.
ad.jp/ja/ip/revise-fee-2012/.
[8] Sun-setting the PSTN,” Critical Legacy Transition Working Group,
2011.
http://transition.fcc.gov/oet/tac/tacdocs/meeting92711/
Sun-Setting\_the\_PSTN\_Paper\_V03.docx.
[9] Sunsetting IPv4 (sunset4) - Charter.
charter/.
86
https://ietf.org/wg/sunset4/
[10] J. Weil, V. Kuarsingh, C. Donley, C. Liljenstolpe, and M. Azinger. IANAReserved IPv4 Prefix for Shared Address Space. Network Working Group
RFC 6598, April 2012. http://tools.ietf.org/search/rfc6598.
[11] 西村雅樹, 宮坂俊成. 2010 年スマートフォン新サービス・機能 - スマー
トフォン向けサービス提供基盤. 18 3, NTT DOCOMO テクニカル・ジ
ャーナル, 2010. https://www.nttdocomo.co.jp/binary/pdf/corporate/
technology/rd/technical_journal/bn/vol18_3/vol18_3_038jp.pdf.
[12] IP アドレス割り当ての運用変更およびグローバル IP アドレスオプション導入
について — UQ WiMAX｜超高速モバイルインターネット WiMAX2+, May
2013. http://www.uqwimax.jp/service/information/201305071.html.
[13] Transcript - APNIC IPv6 Plenary - APNIC 35”, 2013. http://conference.
apnic.net/35/program/apnic-ipv6-plenary/transcript.
[14] Interop Tokyo 2013, 2013. http://www.interop.jp/2013/.
[15] 荒野高志. IPv6 による次世代ネットワークとその応用可能性. Technical
Report 2, 2003. http://www.intec.co.jp/company/itj/itj2/contents/
3.pdf.
[16] V. Fuller and T. Li. Classless Inter-domain Routing (CIDR): The Internet
Address Assignment and Aggregation Plan. Network Working Group RFC
4632, August 2006. http://tools.ietf.org/rfc/rfc4632.txt.
[17] G. Huston. CIDR Report, June 2014. http://www.cidr-report.org/as2.
0/.
[18] 益子直樹, 吉村知夏. インターネットの経路あれこれ. http://www.janog.
gr.jp/meeting/janog28/doc/janog28-isp-after.pdf.
[19] K. Egevang and P. Francis. The IP Network Address Translator (NAT).
Network Working Group RFC 1631, May 1994. http://tools.ietf.org/
rfc/rfc1631.txt.
87
[20] IPv4 アドレス移転の状況とアジア太平洋地域における IPv6 への取り組み状
況について. 総務省 - IPv6 によるインターネットの利用高度化に関する研究
会（第 25 回）. http://www.soumu.go.jp/main_content/000230993.pdf.
[21] APNIC - APNIC Processes First Inter-RIR IPv4 Transfer from
ARIN, October 2012. http://www.apnic.net/publications/news/2012/
apnic-processes-first-inter-rir-ipv4-transfer-from-arin.
[22] 第 7 回 さくらインターネットに聞く“ IPv4 アドレス移転の実際 ”, April
2012. http://gihyo.jp/admin/serial/01/ipv6_guidepost/0007.
[23] IPv6 Enabled Networks. http://v6asns.ripe.net/v/6/.
[24] E. Nygren.
mai
Blog,
A Data-Driven View of IPv6 Adoption.
July
2012.
The Aka-
https://blogs.akamai.com/2012/07/
a-data-driven-view-of-ipv6-adoption.html.
[25] R. Droms. Dynamic Host Configuration Protocol. Network Working Group
RFC 2131, March 1997. http://www.ietf.org/rfc/rfc2131.txt.
[26] Ed. R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney. Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Network Working
Group RFC 3315, July 2003. http://tools.ietf.org/html/rfc3315.
[27] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconfiguration. Network Working Group RFC 4862, September 2007. http:
//tools.ietf.org/html/rfc4862.
[28] J. Arkko and A. Keranen. Experiences from an IPv6-Only Network, 2012.
http://tools.ietf.org/search/rfc6586.
[29] 廣海緑里, 櫨山寛章, 尾上淳, 中村修. 仕様や実装の異なる多数の端末を
IPv6 only ネットワークに接続するための課題と考察. インターネットコ
ンファレンス 2012 (IC2012), pp. 55–62, November 2012.
http://www.
internetconference.org/ic2012/PDF/ic2012-paper08.pdf.
88
[30] 櫨山寛章, 上野幸杜, 佐藤弘崇, 石橋尚武, 横石雄大, 山岸祐大, 石
原 知 洋.
IPv6 only Network 構 築 と 検 証 実 験.
WIDE テ ク ニ カ ル レ ポ ー ト, 2012.
Technical report,
http://member.wide.ad.jp/tr/
wide-tr-hazeyama-ipv6-only-network-00.pdf.
[31] 第 50 回 サイバーエージェントのネットワークインフラを探る［前編］
：サ
イバーエージェントを支える技術者たち｜gihyo.jp … 技術評論社, June 2013.
http://gihyo.jp/dev/serial/01/cyberagent/0050.
[32] 第 52 回 サイバーエージェントのネットワークインフラを探る［後編］
：サ
イバーエージェントを支える技術者たち｜gihyo.jp … 技術評論社, July 2013.
http://gihyo.jp/dev/serial/01/cyberagent/0050.
[33] G. Van de Velde, T. Hain, R. Droms, B. Carpenter, and E. Klein. Local
Network Protection for IPv6. Network Working Group RFC 4864, May
2007. http://tools.ietf.org/html/rfc4864.
[34] D. Thaler, L. Zhang, and G. Lebovitz. IAB Thoughts on IPv6 Network
Address Translation. Network Working Group RFC 5902, July 2010. http:
//tools.ietf.org/html/rfc5902.
[35] T. Chown. IPv6 Implications for Network Scanning. Network Working
Group RFC 5157, March 2008. http://tools.ietf.org/html/rfc5157.
[36] 小柏伸夫, 衛藤将史, 中尾康二. IPv6 環境における攻撃検出回避とその対策.
SCIS 2008, Vol. 2C1-3, , March 2008.
[37] NDPMon — Main / About NDPMon. http://ndpmon.sourceforge.net/.
[38] 北口善明. IPv6 におけるセキュリティ課題の分析. 電子情報通信学会技術研
究報告. ICSS, 情報通信システムセキュリティ, Vol. 112, No. 91, pp. 25–30,
June 2012.
89
[39] E. Davies and J. Mohacsi. Recommendations for Filtering ICMPv6 Messages
in Firewalls. Network Working Group RFC 4890, May 2007. http://tools.
ietf.org/html/rfc4890.
[40] Tokyo6to4.
http://www.tokyo6to4.net/index.php/%E3%83%A1%E3%82%
A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8/.
[41] サービス案内 ｜ OCN IPv6. http://service.ocn.ne.jp/ipv6/overv4/
service/.
[42] ネットワーク事例｜独立行政法人 国立高等専門学校機構 弓削商船高等専門
学校, August 2012. http://ftp.allied-telesis.co.jp/solution/case/
yugeshosen/index.html.
[43] N. Chander. The Business Case for Delivering IPv6 Service Now, May
2012.
http://www.cisco.com/en/US/solutions/collateral/ns341/
ns525/ns1017/idc_ipv6_economics.pdf.
[44] M.
Townsley.
September
2012.
Mapping
Address
+
Port.
RIPE
65,
https://ripe65.ripe.net/presentations/
91-townsley-map-ripe65-ams-sept-24-2012.pdf.
[45] M. Bagnulo, P. Matthews, and I. van Beijnum. Stateful NAT64: Network
Address and Protocol Translation from IPv6 Clients to IPv4 Servers. Network Working Group RFC 6146, April 2011. http://tools.ietf.org/rfc/
rfc6146.txt.
[46] M. Bagnulo, A. Sullivan, P. Matthews, and I. van Beijnum. DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers.
Network Working Group RFC 6147, April 2011. http://tools.ietf.org/
rfc/rfc6147.txt.
[47] D. Wing. Coping with IP Address Literals in HTTP URIs with IPv6/IPv4
Translators. Network Working Internet-Draft, March 2010. http://tools.
90
ietf.org/html/draft-wing-behave-http-ip-address-literals-02.
[48] SixXS - IPv6 Deployment & Tunnel Broker :: SixXS IPv6-IPv4 and IPv4IPv6 Website Gateway/Proxy. https://www.sixxs.net/tools/gateway/.
[49] H. Hazeyama, T. Ishihara, and O. Nakamura.
eral in URL draft-osamu-v6ops-ipv4-literal-in-url-01.
ing Internet-Draft,
January 2014.
IPv4 Address LitNetwork Work-
http://tools.ietf.org/html/
draft-osamu-v6ops-ipv4-literal-in-url-01.
[50] M. Mawatari, M. Kawashima, and C. Byrne. 464XLAT: Combination of
Stateful and Stateless Translation. Network Working Group RFC 6333, April
2013. http://tools.ietf.org/rfc/rfc6877.txt.
[51] Skype bug with 464XLAT / IPv6 - Skype Community, 2013.
http:
//community.skype.com/t5/Android/Skype-bug-with-464XLAT-IPv6/
td-p/1683917.
[52] Skype
Using
On
Android
464XLAT
—
Works
Over
Deploy360
IPv6
On
Programme,
Mobile
Networks
November
2013.
http://www.internetsociety.org/deploy360/blog/2013/11/
skype-on-android-works-over-ipv6-on-mobile-networks-using-464xlat/
f.
[53] X. Li, C. Bao, Ed. W. Dec, O. Troan, S. Matsushima, and T. Murakami. Mapping of Address and Port using Translation (MAP-T) draft-ietfsoftwire-map-translation-01. Network Working Internet-Draft, September
2013. http://tools.ietf.org/html/draft-ietf-softwire-map-t-04.
[54] A. Durand, R. Droms, J. Woodyatt, and Y. Lee. Dual-Stack Lite Broadband
Deployments Following IPv4 Exhaustion. Network Working Group RFC
6333, August 2011. http://tools.ietf.org/rfc/rfc6333.txt.
91
[55] Ed. O. Troan, X. Li, C. Bao, S. Matsushima, T. Murakami, and Ed.
T. Taylor.
Mapping of Address and Port with Encapsulation (MAP)
draft-ietf-softwire-map-09. Network Working Internet-Draft, March 2012.
http://tools.ietf.org/html/draft-ietf-softwire-map-09.
[56] N. Matsuhira. Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation. Network Working Internet-Draft, January 2014. http://tools.
ietf.org/html/draft-matsuhira-sa46t-spec-08.
[57] 松平直樹.
SA46T:IPv4 アドレス枯渇後の IPv6 移行と IPv4 継続利用を
両立するカプセル化技術. インターネットコンファレンス 2012 (IC2012),
November 2012.
http://www.internetconference.org/ic2012/PDF/
ic2012-paper02.pdf.
[58] C.
Byrne.
2014,
464XLAT:
February
Breaking
2014.
Free
of
IPv4.
APRICOT
https://conference.apnic.net/data/37/
464xlat-apricot-2014_1393236641.pdf.
[59] モトローラ株式会社.
ber
2008.
Long Term Evolution (LTE) 技術概要, Septem-
http://www.motorolasolutions.com/web/Business/
Solutions/Industry\%20Solutions/Service\%20Providers/Network\
%20Operators/LTE/_Document/Static\%20Files/LTE_Technical_
JP-JA.pdf.
[60] Over
IPv6
25%
—
of
Verizon
Deploy360
Wireless
Programme,
Traffic
April
Is
Now
2013.
Over
http:
//www.internetsociety.org/deploy360/blog/2013/04/
over-25-of-verizon-wireless-traffic-is-now-over-ipv6/.
[61] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, and F. Jahanian.
Internet Inter-domain Traffic. In Proceedings of the ACM SIGCOMM 2010
Conference, SIGCOMM ’10, pp. 75–86, New York, NY, USA, 2010. ACM.
92
[62] 長健二朗. この 1 年間のトラフィック傾向について. Technical report, Internet Infrastructure Review (IIR), August 2012. http://www.iij.ad.jp/
company/development/report/iir/pdf/iir_vol16.pdf.
[63] 長健二朗. 違法ダウンロード刑事罰化の影響は限定的. Technical report,
Internet Infrastructure Review (IIR), August 2013. http://www.iij.ad.
jp/company/development/report/iir/pdf/iir_vol20_report.pdff.
[64] Android Clat. http://dan.drown.org/android/clat/.
[65] C. Byrne. T-Mobile USA IPv6 Deployment. APNIC 35, February 2013.
https://sites.google.com/site/tmoipv6/464xlat.
[66] 464XLAT – A Solution for Providing IPv4 Services Over and IPv6-only Network - ipv6. http://conference.apnic.net/__data/assets/pdf_file/
0010/58870/tmo-ipv6-feb-2013_1361827441.pdf.
[67] H. Li.
2012.
IPv6 Progress in China Mobile.
APNIC 34,
August
http://conference.apnic.net/__data/assets/pdf_file/0007/
50668/ipv6-progress-in-china-mobile-20120829_1345773579.pdf.
[68] C. Byrne.
464XLAT: Breaking Free of IPv4.
NANOG62, June 2014.
https://www.nanog.org/sites/default/files/wednesday_general_
byrne_breakingfree_11.pdf.
[69] H. Hazeyama, R. Hiromi, T. Ishihara, and O. Nakamura. Experiences from
IPv6-Only Networks with Transition Technologies in the WIDE Camp Autumn 2012. Network Working Internet-Draft, October 2012. http://tools.
ietf.org/html/draft-hazeyama-widecamp-ipv6-only-experience-02.
[70] R.
Hiromi,
H.
Hazeyama,
A.
Onoe,
and
O.
Nakamura.
workaround for termination of IPv4 network services.
Working Internet-Draft, March 2013.
Network
http://tools.ietf.org/html/
draft-hiromi-sunset4-termination-ipv4-01.
93
A
[71] S. Cheshire, B. Aboba, and E. Guttman. Dynamic Configuration of IPv4
Link-Local Addresses.
Network Working Group RFC 3927, May 2005.
tools.ietf.org/html/rfc3927.
[72] Carrier-Grade IPv6：MAP-T（Mapping Address and Port Translation）
の技術概要 - Cisco Carrier-Grade IPv6 ソリューション - Cisco Sys-
tems. http://www.cisco.com/web/JP/solution/isp/cgv6/literature/
solution_overview_c11-726499.html.
[73] ネットワーク｜JANOG31 Meeting, March 2013. http://www.janog.gr.jp/
meeting/janog31/network.html.
[74] 大久保修一, 櫨山寛章, 真野桐郎, 渡邊茂. IPv4/IPv6 共存技術の現状と
ShowNet での相互接続検証結果について (インターネットアーキテクチャ).
電子情報通信学会技術研究報告 = IEICE technical report : 信学技報, Vol.
113, No. 200, pp. 25–28, September 2013.
[75] 宮川晋. 平成 24 年度 IPv4 アドレスの枯渇に伴う情報セキュリティ等の課題
への対応に関する実証実験の請負結果報告, July 2013. http://www.soumu.
go.jp/main_content/000236030.pdf.
[76] 新井イスマイル, 福嶋徹, 内藤岳史, 土川洋史, 比嘉信, 釣健孝, 佐々木智大,
大島秀樹, 渥美清隆, 松野良信, 千田栄幸, 山田悟, 今井一雅, 牛丸真司, 金山
典世, 仲野巧, 寺元貴幸, 脇山俊一郎, 中尾充宏, 村本健一郎. 全国立高専 1 法
人のスケールメリット I∼歴史的 PI アドレスの集約、機器・ソフトの一括調
達、ノウハウ・人材の共有∼. 情報処理学会研究報告. IOT, [インターネット
と運用技術], Vol. 2013, No. 10, pp. 1–5, September 2013.
[77] 国立高専機構 ＞＞ データ. http://www.kosen-k.go.jp/outline4.html.
[78] IPv4 アドレス移転履歴 - JPNIC, 2013. https://www.nic.ad.jp/ja/ip/
ipv4transfer-log.html.
94
[79] 小柏伸夫, 奥田雄一郎. ユビキタス・キャンパス・ネットワークの設計と
構築. 共愛学園前橋国際大学論集, Vol. November, , March 2011. http:
//www.kyoai.ac.jp/college/ronshuu/no-11/ogashiwa.pdf.
95