WIDE Technical-Report in 2012

IPv6 only Network 構築と検証
実験
wide-tr-hazeyama-ipv6-only-network00.pdf

PROJECT

WIDE Project : http://www.wide.ad.jp/

If you have any comments on WIDE documents, please contact toboard@wide.ad.jp

Title:Author(s):Date:

IPv6 only Network 構築と検証実験櫨山寛章 (hiroa-ha@is.naist.jp), 上野幸杜 (eden@wide.ad.jp), 佐
藤 弘崇 (satu@wide.ad.jp), 石橋 尚武 (take@hongo.wide.ad.jp),
横 石
雄 大(dokan@wide.ad.jp),
山 岸
祐 大(yummy@sfc.wide.ad.jp), 石原 知洋 (sho@c.u-tokyo.ac.jp)
2012-1-25

1

はじめに
本章では、2011 年 9 月 6 日から 9 月 9 日の 4 日間にIPv6 only Network 構築と検証実験

開催された WIDE プロジェクト 2011 年 9 月合宿で実施された IPv6 only アクセスネットワーク利用実験に関する報告を行う。WIDE プロジェクトでは、WIDE
合宿の実験ネットワークや WIDE バックボーンにて櫨山寛章 (hiroa-ha@is.naist.jp)
上野幸杜 (eden@wide.ad.jp)
佐藤 弘崇 (satu@wide.ad.jp)
石橋 尚武 (tak@hongo.wide.ad.jp)
横石 雄大 (dokan@wide.ad.jp)
山岸 祐大 (yummy@sfc.wide.ad.jp)
石原 知洋 (sho@c.u-tokyo.ac.jp)

IPv4/IPv6 のデュアルスタック環境の運用を長年行ってきた。また、2011 年 6 月に実施された World IPv6 dayの前後で多くの商用 ISP が IPv6 接続サービスを提供開始した。一方で、実際に IPv6 だけ提供されるアク
セスネットワークとアドレス変換サービスを利用した
場合、現在提供されている IPv4 もしくはデュアルス
タックによる接続サービスと比較して、どの程度利用できるのかに関しての知見は、世界的に見てあまり蓄積されていない。そこで、IPv6 のみを利用してどこま2012 年 1 月 17 日

でサービスネットワークとして構築し、提供できるかという点と、IPv6 しかない環境ではユーザの利用においてどのような問題が生じるのかを洗い出すために、

概要

WIDE 合宿ネットワーク全体のテーマとして IPv6 only
network に着目して合宿ネットワークを設計し、構築、

2011 年 9 月 WIDE 合宿の実験のメインテーマとし運用した。

て、参加者に DHCP6 と DNS64/NAT64 のアドレス変換による IPv6 only アクセス環境のみを基本的に提供し、ユーザが普段利用している OS やアプリケーション

2の IPv6 対応状況の確認や、IPv6 のみを有効にする設定
や IPv6 only アクセス環境で快適に生活するための知The Camp 1109 ネットワークの設
計

見、NAT64/DNS64 を実際に利用した際の問題点の洗合宿ネットワーク全体のテーマとして、IPv6 only

い出しを行った。また、IPv4 コネクティビティの提供

network を構築し、参加者全員が IPv6 only network で方法として SA46T による 464 トンネルを用いて WIDE

生活するという方針は、2011 年 5 月に北陸先端科学技

バックボーンの IPv4 グローバルアドレスを MAC アド

術大学院大学で実施された WIDE 研究会の研究発表に

レス登録制の DHCP4 で提供し、あわせて、IIJ で開発て議論され、決定した。しかしながら、WIDE 合宿参している SEIL 4RD ルータと vyatta の 4RD 拡張を用

加者の多くは、特に企業からの参加者は、社内ネット

いて 4RD による IPv4 プライベートアドレスの提供実

ワークサービスが IPv6 に対応していないことが多く、験を行った。2 つの IPv4 提供実験はともにアドレス変IPv6 接続性のみを提供しても日常の業務（メールの換、トンネリング技術である。また、対外線を IPoE 方閲覧など）を実施することができない。そこで、合宿

式で提供される IPv6 インターネット接続サービスのみ

ネットワーク準備委員会（以降 Net PC）では、WIDEを利用し、慶應義塾大学 上野によって作成された IPv6

合宿の実験ネットワーク（camp-net）にて、参加者が用 LT2P を用いて WIDE バックボーンへの L2 トンネルを作成し WIDE バックボーンからのルーティングを

EMOBILE などの商用モバイルインターネットサービ
スに退避せずに 4 日間生活できる、現実的なサービス

おこなうため、多重カプセリングの影響を把握する検として IPv6 only network 環境の提供方法の模索を始め証も参加者を交えて実施した。

た。本節では、合宿ネットワーク NOC チームで検討し、いくつかの事前検証を通して設計した camp-net の1

概要、実験趣旨および技術解説を行う。

た。9 月 6 日午後 8 時までは、図 1(a) に示すように、

2.1 実験概要
まず、NOC チームにより、1）DHCP6 の利用実験、

camp-net で用意した L2TP ゲートウェイに FTTH 回線
上の RA で割り当てられる/64 プレフィックス長の IPv6
アドレスを設定した。一方、9 月 6 日午後 8 時以降は、
図 1(b) に示すように、IIJ が研究開発している SEIL

2）NAT64 / DNS64 による IPv6 / IPv4 アドレス変換

ホームルータの WAN 側インターフェースに FTTH 回の利用実験、3）SA46T による IPv6 バックボーンを

線上の DHCP6 で割り当てられる/48 プレフィックス長介した IPv4 ネットワーク接続性提供実験、4）WPA2の IPv6 アドレスを割り当てて、4RD のための prefix

EAP-TLS による無線 LAN アクセス認証、の 4 つの実
験を実施した。これに合わせて、慶應義塾大学、IIJ、

delegation を実施できる構成に設定した。
また、WIDE プロジェクトで運用管理する IPv6 アド

NTT 東日本、インターネットマルチフィードによってレスブロックを合宿ネットワークで利用するために、構成された実験チームによる 4RD による IPv6 および松代ロイヤルホテルと慶応 SFC の間を結ぶ L2TP トン

IPv4 ネットワーク接続性提供実験が実施された。

ネルを FTTH 回線上に構築した。L2TP ゲートウェイはLinux Debian squeeze (kernel 2.6.32) で構築したサーバ
上に NOC の一人である上野が作成した IPv6 用 L2TP

2.2 対外接続

実装 (v6tun [1]）を用いた。筑波大学で開発されてい図 1 に示すように、今回の camp-net では IPv6 によるオープンソース VPN ソフトウェアである ut-vpn [2]る 2 つの対外線を用意した。ひとつは松代ロイヤルホと比較した事前検証では、v6tun は TCP で 719 Mbps、

テルと慶応大学湘南藤沢キャンパス（SFC）を結ぶ衛星回線であり、もうひとつは NTT 東日本により提供

UDP で 738 Mbps のスループットを記録し、他方、utvpn [2] は TCP で 428 Mbps、UDP で 410 Mbps のス

された FTTH 回線である。

ループットであったため、L2TP として v6tun を採用した。

まず衛星回線に関して説明する。衛星回線は 1.5GHz
帯を用いた回線で下り 1.5Mbps, 上り 512 Kbps の回線
利用申請を行った。衛星回線は合宿会期中通して安定2.3していた。衛星回線を挟み SFC 側のルータと camp-net

NAT64 / DNS64

今回の camp-net ではユーザへの IPv6 アドレス割りのコアルータとの間で VLAN を構築した。
次に、FTTH 回線について説明する。FTTH 回線で当てを ISC DHCP6 実装 [3] を用いて提供した。一方、は NTT 東日本をアクセスキャリア、インターネットマ

多くのネットワークが World IPv6 day を経験した後でルチフィードを VNE （Virtual Network Enabler）、IIJ

も IPv6 に未対応であるため、6to4 アドレス変換技術

を IPv6 ISP として構成された 2 種類の商用 IPv6 アクを camp-net の IPv6 only 接続性実験に組み入れること

セスサービスを検証した。設営に当たる 2011 年 9 月 5とした。そこで、camp-net の要求を満たす、2011 年 9日から 9 月 6 日午後 8 時まではフレッツ光ネクストの月現在で構築可能な最良の NAT64 [4, 5] と DNS64 [6]IPv6 オプション付きの契約を行い利用した。9 月 6 日を用いた 6to40 アドレス変換の実装を検証した。

NOC チームの NAT64 および DNS64 への技術要求

午後 8 時からは、4RD の検証を実施するために、さら事項は以下のとおりである。

に光電話オプションをつけて再契約およびオプション
変更に伴う工事を実施し利用した。光電話オプション

実装はオープンソースソフトウェアであることのあり・なしの差異は、光電話オプションなしでは IPv6

理由は、何らかのトラブルが発生した場合にデバッ

は RA にて/64 の IPv6 アドレスが割り当てられ、一方、グが NOC チームによって行えるようにするため

光電話オプションありの場合は DHCP6 により/48 のである。

IPv6 が割り当てられる。FTTH 回線の変更を図示する

正常に動作する DNS64 実装であることと図 1(b) のようになる。

理由は、正常に動作しない実装をサービスに用い

IPv6 インターネットへの接続性は IIJ mio FiberAc-

ることはできないためである。

cess/NF for IPv6 ネイティブサービスを契約し利用し2

表 1: 無線 LAN 設定と接続性、アドレス変換技術の一覧
ESSID

Accounting

Channelwidecamp

WPA2
EAP-TLS

11b/g/nwidecamp-a

WPA2
EAP-TLS11awidecamp-sat

WPA2
EAP-TLS

11b/g/nwidecampnowep(hidden)

MAC addr.
Auth.

11b/g/nwidecamp-iij

WPA2
EAP-TLS

11b/g/n

WPA2
EAP-TLS

11b/g/nwidecamp4rd

Addressversionv6

Address
scope
globalDNS

v4

global

DNS64

v6

global

DNS64

v4

global

DNS64

v6

global

DNS64

v4
v6

N/A
global

N/A
DNS64

v4

global

DNS64

v6

global

N/A

v4
v6

N/A
global

N/A
N/A

v4

privateProxyresolver

正常に動作する NAT64 実装であること

DNS64

Address
allocation
DHCP6(automatic)
DHCP4(registration)
DHCP6(automatic)
DHCP4(registration)
DHCP6(automatic)
N/A
DHCP6
(automatic)
DHCP4(registration)
RA from SEIL
(automatic)
N/A
RA from SEIL
(automatic)
DHCP4
from
SEIL
(automatic)

Trans. /Encap.
NAT64
SA46T
NAT64
SA46T
NAT64
N/A
NAT64
SA46T
N/A
4RD
N/A
4RD

必要とするが、NAT44 のカスケードを利用しないといDNS64 と同様に正常に動作しない NAT64 実装をサービスに用いることはできないためである。特う要求事項と、camp-net で参加者全員を収容できるほに変換によってペイロードを破壊しない事が必須

ことから、検討段階で tayga ステートレス NAT64 は要である。

求事項を満たせなかった。次に、linuxnat64 と ecdysis

ど十分なグローバル IPv4 アドレスを保持していないを実際に動作させて評価したところ、2011 年 7 月の段他の NAT44 とのカスケード接続を利用しないこと

階では、ecdysis の実装では TCP ペイロードを破壊す

理由としては、NAT64 のみの不具合を正しく把握る挙動が確認されたため、特に不具合もなく正常に動し、カスケード接続によって生じる可能性のある作した linuxnat64 を camp-net では採用した。bind とトラブルを回避するためである。

linuxnat64 の設定例は 7 章に付録として記載しておく。

DNS64 と NAT64 の実装の評価はプレホットステー
ジ期間である 7 月 1 日から開始した。まず、DNS64

2.4の実装に関する評価について説明する。評価対象とIPv4 over IPv6 カプセル化技術

した DNS64 の実装は ISC bind 9.8 p4 [7]、NLnet labs

6to4 アドレス変換とは別に、camp-net では IPv6 未unbound [8] および Viagénie ecdysis [9] の 3 種類を検対応の OS やアプリケーションを利用する参加者のた証した。このうち、2011 年 7 月の段階で正常に動作しめに、464 カプセル化技術の検討も行った。camp-net

たのは bind のみであったため、camp-net で用いる実NOC が公式サービスとして用意する 464 カプセル化

装として bind を採用した。

技術としては SA46T [12–15] のソフトウェア実装を採次に NAT64 の実装に対する評価イについて説明用した。この SA46T ソフトウェア実装は慶應義塾大学

す る 。評 価 し た NAT64 の 実 装 は linuxnat64 [10]、と富士通との共同研究で研究開発され、過去の WIDE

tayga [11] および ecdysis [9] の 3 種類である。
linuxnat64 と ecdysis は ステートフル NAT64 [5] の合宿での実験や JGN-X と ThaiSARN との間でのビデ実装であり、一方、tayga はステートレス NAT64 [4] のるため採用した。

オストリームを用いた検証 [16] などによって実績があ実装である。評価の結果、camp-net では linuxnat64 をまた、追加実験として 4RD [17] の検証も実施した。

採用した。採用した理由は、まず、tayga のステート

4RD 検証実験は慶應義塾大学、NTT 東日本、インターネットマルチフィードおよび IIJ によって構成された

レス NAT64 は収容するユーザ数だけ IPv4 アドレスを

3

4RD 検証チームから 9 月 1 日に急遽提案され、campnet でこの実験を受け入れたことによって実施が決まった。4RD 検証実験では IIJ が開発している SEIL ホー
ムルータ上での 4RD 実装を 4RD-CE (4RD Customer
Edge Router) として合宿地に設置し、vyatta の 4RD 実

境に構築した。利用したクラウド環境は、StarBED [20]上の CISCO UCS サーバを 6 台と WIDE 藤沢 NOC に設置した WIDE Cloud Controller (WCC) [21] のクロー
ンサーバを用いて構築した。藤沢の WCC サーバはクラウド環境のコントローラおよび NFS サーバとして利用

装 [18] を 4RD-BR（4RD Boarder Router) として WIDE

し、StarBED 上のサーバは仮想マシンを配置するスレ

バックボーン藤沢 NOC 内に設置した。4RD-CE で IPv6

イブノードとして利用した。仮想マシンとしては qemu-

パケットにカプセリングされた IPv4 パケットは NTT

kvm 0.14.1、Linux Kernel 3.0.4 を用い、libvirt 0.9.4 を

東日本のフレッツ網からインターネットマルチフィード

用いて仮想マシンの操作を行った。また、StarBED とのバックボーンを経由して IIJ の IPv6 網に入り、そこ藤沢の WCC サーバ間は WIDE バックボーン上に広域から WIDE バックボーンにルーティングされ 4RD-BR

VLAN を設定して同一 L2 セグメントに収容できるよで IPv4 パケットに戻されることになる。

うにした。詳細は、第 4 部 「クラウドコンピューティ
ング基盤の構築と運用」や第 28 部 「大規模な仮設ネッ

2.5

トワークテストベッドの設計・構築とその運用」を参WiFi アクセスとアドレス割り当て

照してほしい。

ユーザアクセス周りのトポロジーは図 1(c) に示すような構成とした。また、表 1 では図 1(c) に対応した無実験

3線 LAN のチャネル、認証方式、VLAN、利用 IP アドレ
スタイプ、IP アドレスの割り当て方、アドレス変換方式

本節では、実験結果について報告する。前節まででの一覧である。基本的に、無線 LAN アクセスは WIDE

述べたように camp-net では「WPA2 EAP-TLS による個人証明書を用いた WPA2 EAP-TLS により提供した。

アクセス認証の検証」、「NAT64/DNS64 による IPv6

WIDE 個人証明書を用いた WPA2 EAP-TLS による無only アクセス環境の検証」、「SA46T による 464 カプ

線 LAN アクセス認証は 2008 年 3 月合宿から camp-

セル化の検証」、「4RD による 464 カプセル化の検証」

net NOC により継続して行われている実験である。まの 4 つの実験が行われた。

た、ESSID widecamp-nowep を、WPA2 EAP-TLS が行えないデバイスや個人証明書をインストールし忘れ

3.1

たユーザのためのバックアップとして隠し ESSID に設定して用意した。ESSID widecamp-nowep での認証

実験概要とタイムライン

表 2 は合宿期間中に発生したイベントのタイムライ

は文献 [19] で説明されている radius を用いた MAC アンを示す。「WPA2 EAP-TLS によるアクセス認証の検ドレスと接続 AP の対応によるレイヤ 2 レベルの認証

証」と「NAT64/DNS64 による IPv6 only アクセス環（アカウンティング）により行った。

境の検証」は 9 月 6 日の午前 10 時から開始した。初IP アドレス自動割り当てと名前解決用のリゾルバ

日（9 月 6 日）の段階では、widecamp-nowep およびの自動設定は ISC DHCP 実装 [3] を用いて DHCP4 とSA46T を通した IPv4 グローバルアドレスによるアク

DHCP6 を提供した。ただし、ESSID widecamp-4rd でセスを行うための MAC アドレス登録ページは隠したは 4RD-CE として動作している SEIL ホームルータが状態で、IPv6 のみのアクセス環境を参加者に強制的にRA、NAT44、DHCP4 および name proxy として動作利用させるようにした。WIDE 個人証明書の入れ忘れしているため、SEIL ホームルータによって IP アドレなどで IPv4 アドレスで構築された社内網にアクセス

スと名前解決用のリゾルバの自動設定を行った。

しなければならないと言った IPv4 アドレスが必要な参加者には、NOC にヘルプデスクを用意し個別対応を行った。

2.6 物理機材およびクラウド資源の活用

また、EMOBILE などの商用モバイルインターネッ

松代ロイヤルホテルでの設営作業を省力化するため

トと個人用 WiFi ルータを持ちこむ参加者は昨今増えに、2011 年 9 月合宿ではほとんどのサーバをクラウド環

4よるグローバル IPv4 アクセスを利用するための MAC

表 2: Time line of experimentsDate
2:00 PM, Sep. 5th
4:00 PM, Sep. 5th
4:50 PM, Sep. 5th
3:00 AM, Sep. 6th
9:00 AM, Sep. 6th
10:00 AM, Sep. 6th
8:00 PM, Sep. 6th
9:00 PM, Sep. 6th
10:00 PM, Sep. 6th
1:30 PM, Sep. 7th

3:15 PM, Sep. 7th
4:15 PM, Sep. 7th
5:47 PM, Sep. 7th
10:00 PM, Sep. 7th

1:42 PM, Sep. 8th
4:30 PM, Sep. 8th
5:30 PM, Sep. 8th
6:00 PM, Sep. 8th
8:00 PM, Sep. 8th
10:00 PM Sep. 8th
11:00 PM Sep. 8th
11:00 AM Sep. 9th
2:30 PM Sep. 9th

アドレス登録ウェブページを開設し、参加者にグローバ

Events
設営開始
FTTH 回線上への IPv6 L2TP トンネルの設定終了
衛星回線の設定終了
DHCP ヘルパーの動作不良（チェックサムエラー）を特定、camp-net トポロ
ジーから削除衛星回線の動作検証終了
started the WPA2 EAP-TLS の検証とDNS64/NAT64 による IPv6 only アク
セス環境の検証を開始
4RD 検証実験のための FTTH 回線の設定変更を開始
4RD 検証実験のための FTTH 回線の設定変更が終了
4RD 検証実験のための設定終了と NOCチームでの事前検証開始
SA46T による IPv4 アクセス環境用のMAC アドレス登録ページを開設し、SA46T による IPv4 アクセス環境を参加者に解放
合宿参加者を交えた 4RD 検証実験の開始
fixed the mis-configuration of firewall on
MAC アドレス登録ウェブサーバ上のfirewall の設定ミスを特定し、修正
radius サーバの設定ミスを特定し、修正ほぼすべての参加者が WPA2 EAP-TLS
または widecamp-nowep で ESSID のい
づれかに接続し、検証実験に参加できる状態になったことを確認
DNS64 サーバ上で DNSSEC を有効にする
有志による SA46T および 4RD のパ
フォーマンス測定開始
ns.wide 上の設定ミス（lame delegation）
を特定、修正負 荷 向 上 に よ り、DNS64 サ ー バ をWIDE クラウド上から独立した物理サー
バへ移行
有志による SA46T と 4RD の比較検証
開始
FTTH 回線のパフォーマンスチューニ
ングを開始
FTTH 回線のパフォーマンスチューニ
ング終了
camp-net を停止、撤収開始
撤収終了

ル IPv4 アクセスの利用を開放した。また、9 月 7 日午
後 3 時 15 分から 4RD による NAT44 を介した IPv4 ア
クセスの利用を参加者に開放した。上記のタイムライ
ンから、ほとんどの参加者は少なくとも丸 1 日は IPv6
のみのアクセス環境で会場では過ごしたことになる。

3.2

アンケート

ここでは実験に対して参加者に行ったアンケート結果を報告する。アンケート結果は WIDE プロジェク
トのメンバーであれば [22] で閲覧することができる。

2011 年 9 月合宿参加者は総数 153 名でそのうち 2011年 9 月 17 日の午後 1 時半までにアンケートに回答した参加者は 110 名、回答率 71.9% であった。図 2 は参加者が利用したアクセスネットワークの組み合わせの割合、および NOC が実施した実験（IPv6 only および

SA46T）に対する回答の集計結果である。一方、図 3 は
4RD 検証実験に対するアンケートの集計結果である。
図 2(a) は参加者が利用したアクセスネットワークの組み合わせの割合を集計した結果でさる。驚くことに30 名（19.6%）の参加者が合宿期間中を通して NAT64/ DNS64 によるアドレス変換を伴う IPv6 only のアク
セスネットワークだけで生活したと回答した。IPv6 とSA46T による IPv4 アクセスネットワークを利用したと申告した参加者は 7 名いた。解析したところ、初日の WPA2 EAP-TLS の設定または IPv6 only 設定に失敗
し、IPv4 アドレス利用が開放された段階で SA46T による IPv4 アクセスネットワークに逃げ込んだ参加者が多かった。33 名の参加者は IPv6 と 4RD 環境を利用しているため、初日は NOC チームで Fox Hunting チー

たと申告した。これらのユーザは MAC アドレス登録

ムを結成し、個人用 WiFi ルータによる rouge AP の取をしてまで IPv4 アクセスを利用しようとは思わなかっり締まりを実施した。rouge AP を用いて IPv4 ネット

たユーザではないかと推測できる。34 名の参加者はワークにアクセスしていた参加者に対しては、ホテル

全ての組み合わせを試し、その多くは 4RD と SA46Tの宿泊部屋で松代ロイヤルホテルが用意している IPv4の比較実験に参加した参加者であった。図 2(c) および

ネットワークを使うか、rouge AP として実験に影響し

図 2(d) から 90 名の参加者（58.8%）は今回 camp-net

ない程度に会場から遠く離れて利用する、または NOCで提供した IPv6 only アクセスの品質や SA46T で提供のヘルプデスクにて有線で提供しているの SA46T 経

した IPv4 アクセスの品質に満足したようであった。

由の IPv4 ネットワークを利用するように促し、できる

SA46T や 4RD などの IPv4 アクセスを利用した主な限り IPv6 only アクセス環境の検証実験に参加するよ理由を以下に列挙する。

うに取り組んだ。

理由 1) 持ってきた PC に WIDE 個人証明書を入れ忘れ

表 2 に示すように、9 月 7 日午後 1 時半に SA46T にたが、メールサーバが IPv4 のみで DNS 登録もさ5

れていないため、ssh でログインするために IPv4

3.3.1

アクセスを利用した。

WPA2 EAP-TLS に関するトラブル

不幸なことに、9 月 6 日から 9 月 7 日かけて最も多かったトラブルは WPA2 EAP-TLS に関するトラブル

理由 2) 利用している OS（Windows XP や Mac OS X

であった。

10.5.8 など）で IPv6 設定が行えなかった、もしく

WPA2 EAP-TLS に関するトラブルで最も多かった

は設定の仕方がわからずあきらめた。

項目は「WIDE 個人証明書の入れ忘れて来てしまった理由 3) Lenovo ThinkPad’ の無線 LAN 設定では IPv6

が、メールサーバが IPv4 のみなのでどうしたらよいの

only の設定がうまく設定できなかったため、IPv4か？」という相談であった。NOC ヘルプデスクに直接相アクセスを利用した。

談に来た参加者には MAC アドレスの登録を手動で行

理由 4) skype や windows live messanger などの IPv6

い widecamp-nowep もしくは有線接続で SA46T によonly 環境に未対応のアプリケーションを仕事で利用するために、IPv4 アクセスを利用した。

る IPv4 アクセスを利用し、NOC のサポートで WPA2

EAP-TLS の設定を行った。しかしながら、NOC ヘル
プデスクに相談しにくる参加者は少なく、相談しに来理由 5) IPv4 アドレスしか設定されていない会社のなかった参加者は自分の部屋で松代ロイヤルホテルがVPN サーバ（IPsec VPN または PPTP）に接続するために、IPv4 アクセスを利用した。

提供する IPv4 アクセスを利用するか、商用モバイルイ
ンターネットサービスを使い、rouge AP を立ち上げて理由 6) Andoroid OS で WPA2 EAP-TLS を設定しよいることを NOC 注意されるという参加者が多かった。

うとしたが、名前解決を IPv4 で行っている挙動

また、9 月 7 日まで radius サーバの設定ミスがあり、認証が不安定であったこともトラブルとして上がった。

を示したので IPv4 アクセスを利用した。

設定ミスは WIDE moca ワーキンググループの木村泰

理由 7) あるウェブページが AAAA での名前解決時

司氏らの手助けにより、9 月 7 日中に解決された。

に ServFAIL エラーを返し、閲覧できなかったた
め、IPv4 アクセスを利用した。

3.3.2

IPv6 対応に関するトラブル

理由 8) DNS64 の応答速度が遅くなったため、IPv4 ア
参加者からは次のような IPv6 対応に関するトラブ

クセスを利用した。

ルが報告された。
理由 9) VMWare の NAT から外部にアクセスできな• フォールバックルーチンが長すぎるくなったために、IPv4 アクセスを利用した。
理由 10) SA46T と 4RD の比較検証実験に参加するた

IPv6 only アクセスに接続したほとんどの参加者

めに IPv4 アクセスを利用した。

がこのトラブルを報告した。このトラブルは Win-dows ユーザや Mac OS ユーザから多く報告された。このトラブルの原因は、Windows 7 や Mac OS

図 3(b)、図 3(c)、図 3(d)、図 3(e) および 図 3(f) は

4RD 検証結果に対するアンケート結果をまとめたものである。ほとんどの参加者は提供された 4RD 環境に満足した。しかしながら、一部の参加者から 4RD 環境

X では IPv4 プロパティが有効になっている場合、接続時に IPv4 の対外接続性の確認も行っているでの不具合が報告された。報告された不具合に関してためで IPv4 接続確認のタイムアウトで 1 分から

は次節 3.3 に記載する。

2 分待たされるためである。NOC チームからの推奨設定として、IPv6 only アクセス環境で IPv4 を使わない場合は IPv4 プロパティを無効にするこ

3.3 報告されたトラブルとをアナウンスした。実際に設定した参加者の多くは「IPv4 の設定を無効にするのは衝撃的だが、本節では NOC や合宿参加者メーリングリストに報

実際、非常に快適になった。」と回答した。

告されたトラブルをまとめる。

6

• DHCP6 未対応によるトラブル

アプリケーションに関するトラブル

3.3.3

ここでは、参加者から報告された、特定のアプリケー

Windows XP や Mac OS X 10.6 (Snow Leopard) 以
前の OS では DHCP6 に対応していないため、DNS
リゾルバの設定の仕方がわからないという参加者

ションに関するトラブルを記載する。

• アプリケーションの IPv6 未対応に関するトラブ
ルが多く存在した。NOC チームでは、DHCP6 未対
応の OS と手動で設定する DNS サーバのアドレ
スをアナウンスし、設定方法がわからない参加者

Arkko がインターネットドラフト [23] で指摘しては NOC ヘルプデスクにて対応した。

いるように、インスタントメッセンジャーや VoIP

一方で、Windows 7 や Mac OS 10.7 (Lion）を利用

アプリケーションの多くはやはり IPv6 未対応のしていた参加者からは DHCP6 や DNS リゾルバ

ものが多く、利用できなかった。

設定に関するトラブル報告はほとんどなかった。

また、CVSNT や NOD32 のウィルスデータベー

例外として、Think Pad などの無線 LAN アクセス

スアップデートなど、おそらく IPv4 ソケットしか設定アプリケーションを利用していた参加者から利用していない Windows 上のアプリケーション

は設定がうまく反映されないとの報告を受けた。

がいくつか確認された。

• OS で IPv6 のみの設定ができないことによるトラ

Mac OX X では、Cocoa フレームワークで実装

ブルされたアプリケーションは IPv6 only 環境で動作

Windows XP や Android OS (バージョン 2.x のデバイス）では IPv4 プロパティを無効にできない。

し、Cocoa フレームワークを利用していないアプ

Windows XP の場合、DNS 名前解決でローカルプ
ロキシを 127.0.0.1 で立ち上げて利用しているたないとの報告を参加者から受けた。

めである。Android OS に関しては詳しい原因調査

ションの多くは利用できた。利用できない HTTP

を行えなかったが、参加者からは「おそらく名前

ベース、XMPP ベースのアプリケーションはサー

解決は IPv4 パケットを使っているようだ」といバへのアクセスに対し IPv4 アドレス表記をアプう報告が挙げられた。

リケーション内で埋め込まれているようであった。

リケーションの多くは IPv6 only 環境で利用でき
また、HTTP ベース、XMPP ベースのアプリケー• GUI、デバイスの IPv6 未対応によるトラブル• MTU ブラックホールによるトラブル
Path MTU ディスカバリが正常に動作しないこと

いくつかの GUI やハードウェアで IPv6 未対応に関に起因する MTU サイズの不整合でパケットが破連するトラブルが報告された。初期型の Mac Book棄される問題を MTU ブラックホールと一般的にAir で Snow Leopard を用いていた参加者から、呼称する。この MTU ブラックホールに関するトGUI で設定した DNS64 の設定がいつの間にか消えラブルもいくつか発生した。

てしまうというトラブルが報告された。NOC で調

まず、9 月 5 日の設営時に WIDE クラウド上を経査したところ、“sudo networksetup -setdnsservers

由するパケットが軒並み破棄されるというトラブ”AirPort” 2001:200:0:ff80::5” をコマンドラインから実行すると設定が消えない事が判明したため、ルに遭遇した。これは WIDE クラウドの MTU サ

これを回避方法として指定した。また、参加者がMTU サイズを 1500 に設定することで回避した。

イズが 9000 に設定されていることによるもので、持ち込んだ Apple 社の USB イーサネットアダプ

次に、UDP を用いたアプリケーションで L2TP 上

タは IPv6 に未対応であることや、古いデバイス・を経由しているパケットで MTU ブラックホール

古い OS を利用している参加者からデバイスドラと思われるトラブルが参加者から報告された。残イバの再インストールを頻繁に行ったという報告

念ながら NOC チームではこのトラブルの原因をを受けた。

合宿中に解析できなかった。

7• アドレス・プロトコル変換へプロトコル仕様上対応していないことによるトラブル
Open VPN や Apple Mobile Me IPSec / PKI ベースの通信など IPSec を用いているアプリケーション
はその仕様上 NAT64/DNS64 のアドレス変換には

ホットステージ期間中の検証で、一部の商用ウェ
ブサービスが AAAA の逆引きを要求してくることが明らかとなった。そのため、NOC チームでは

camp.wide.ad.jp ドメインで利用する全てのIPv6 アドレスに対し逆引きを設定した。

対応できない。そのため、多くの参加者から IPv6

• lame delegation によるトラブル

only アクセス環境で会社への VPN が利用できな
いというトラブルの報告を受けた。また、4RD の合宿期間中に、ある参加者から一部の商用ウェブ
サービスが AAAA の逆引きを要求してきているが環境でも、ある参加者から Apple Mobile Me IPSec

逆引きができていないという指摘を受けた。NOC/ PKI ベースの通信が行えないというトラブルのチームで調査した結果、camp.wide.ad.jp ド報告を受けた。こちらの原因特定は残念ながら期メインの上位ドメインである wide.ad.jp ドメ

間中に実施できなかった。

インを管理する ns.wide.ad.jp 上の設定ミスで lamedelegation が発生していることが明らかとなった。
3.3.4 名前解決に関するトラブル

設定ミスを修正することでこの問題は解消された。

ここでは名前解決に関するトラブルを報告する。

• DNS64 の負荷による応答速度劣化によるトラブル• IPv4 アドレス表記に関連するトラブル

DNSSEC を DNS64 サーバで有効にしたあと、Arkko のインターネットドラフト [23] でも指摘されているように、多くの参加者から IPv6 only アク

DNSSEC の検証や参加者のアクセス増加により
DNS64 の負荷が向上し応答速度劣化によるトラ

セス環境から IPv4 サーバに対し IPv4 アドレス表

ブルが発生した。当初 DNS64 は WIDE クラウド

記で通信できないというトラブルの報告が挙げら上の仮想マシンとして動作させていたが、急遽独れた。これは、IPv4 アドレス表記を用いると、た立した物理サーバとして再構築し、負荷の解消をとえ getaddrinfo のような IPv6 対応ソケットを用い行った。物理サーバに移行した後は、特に負荷にたとしても、NAT64/DNS64 の仕様上、DNS64 による応答速度の劣化は生じなかった。

より指定された IPv6 mapped IPv4 アドレスでユー
ザ側のソケットを作成しないためである。HTTP、

SSH、IMAP、SMTP、POPFile などのアプリケー• 不適切な AAAA 応答を返す権威サーバに関連するトラブル

ションの設定で指定するサーバを IPv4 表記で書

合宿期間中、一部のウェブページで NAT64/DNS64

いていたり、サーバのアドレスが IPv4 表記で組

で名前解決が失敗し閲覧できないというトラブル

み込まれていたりする場合に発生する。設定変更が多くの参加者から報告された。この現象は国内外できるものに関しては、対象となる IPv4 アドレ

問わず、航空券・ホテル検索ページで頻繁に発生しスを DNS に登録したうえで、アプリケーションていた。NOC チームと有志により解析したところ、側の設定を FQDN で設定すれば動作するが、参この原因は RFC 4074 [24] で指摘されている IPv6

加者の多くが DNS 管理者ではないため、DNS に

移行期に発生する可能性のある不適切な AAAA

登録されていない IPv4 アドレスに対応できない応答を返す権威サーバにより DNS64 が AAAA レ

ケースが散見された。

コードの問い合わせから A レコードの問い合わせ

また、VNC、PPTP、IPSec などのアプリケーショにフォールバックせずにエラーコードをクライアンはこの IPv4 アドレス表記による問題とともに、ントに返してしまう現象により発生していること

プロトコル仕様上の問題や MTU ブラックホールが明らかとなった。エラーとしては RFC 4074 [24]の問題も重なり、切り分けが非常に困難であった。

の 4.2 節で述べられている “Return Name Error”、

4.3 節で述べられている “Return Other Erroneous
Codes”、4.4 節で述べられている “Return a Broken• AAAA 逆引きが設定されていないことによるトラ
ブル
8

Response” を実際に観測した。これらのエラーは権威サーバの実装に起因するものなので NOC チー
ム側では解決できないトラブルであった。

ここでは、今後の研究課題として広く議論しなければいけない項目を述べる。

4 考察
4.1

研究課題

4.2

4.2.1

IPv6 環境への移行における提言

PMTUD、MTU ブラックホール問題

今回の実験では MTU ブラックホール問題はさまざ
ま個所で発生した。主原因は Path MTU ディスカバリ

ここでは、合宿ネットワークでの実験で得た知見をが運用上の理由やアドレス変換・カプセリングが挟まっ通した、NOC チームからの IPv6 環境への移行におけた段階で正常に動作しないことに起因している。一方る提言を記載する。

で VPN などの多くのトンネル・カプセル化技術では

PMTUD が正常に動作していることを前提に実装され• IPv6 対応が可能であれば外部からアクセスのあているものが多い。

るサーバは IPv6 対応すべきである

理由としては、今回の実験から NAT や NAPT を挟可能性のある解決方法としては、RFC 規約違反であんだ環境では容易に MTU ブラックホール問題やるが、DF bit が設定されていてもルータや VPN ゲー

スループット低下など、様々な問題が生じ、切りトウェイでフラグメントを行うように実装することが分けが難しいため、デュアルスタックなどで IPv6考えられる。また、MTU ブラックホールが発生して対応できるのであれば、今のうちに対応してしまいる個所を効率よく特性する手法が現在確立していなうのが得策である。

いこともあり、そのような検証ツールの研究開発も必要である。

• 最新バージョンの OS に移行すべきである

理由としては、Window 7 や Mac OS X 10.7 (Lion)

4.2.2

からのトラブル報告はほとんどなく、一方で古いバージョンの OS を利用した参加者からは様々な

RFC 4074 で指摘されている不適切な DNS 応答

3.3.4 節で説明したように、RFC 4074 [24] で指摘さトラブルの報告を受けたため、運用コスト上は最れている不適切な DNS 応答にどのように対応するか

新バージョンの OS に移行したほうがよい。

も研究課題の一つである。理想的には全ての DNS リ• AAAA の逆引き設定をすべきである

ゾルバ実装が RFC に則った実装に改修されることでブサービスが存在するためである。

可能性のある解決方法としては、DNS64 のフォールあるが、非常にコストが高い。

理由は AAAA の逆引きを認証に利用する商用ウェ

バックの仕様を次のように変更することである。

• DNS サーバやウェブアプライアンスの DNS 応答• NXDOMAIN や ServFail が AAAA 応答で返されても A 要求を出すように DNS64 の仕様を変更する。

が RFC に則っているか否かの検証をしたほうがよい
理由としては、不適切な DNS 応答はクライアン• DNS64 側でアクセスされる可能性のある A レ

ト側では対応できないためである。RFC に則った

コードをあらかじめ探索しキャッシュしておく。

応答を返せばウェブサービスが IPv6 対応していDNS 応答が NOERROR の場合、DNS64 リゾル

なくても DNS64/NAT64 のアドレス変換によってバは AAAA 要求を発行する。仮に AAAA レコー

IPv6 only ネットワークからもウェブサービスを利ドが存在すれば DNS64 リゾルバはクライアント

用できる。

に対し AAAA レコードを返し、そうでなければキャッシュされている A レコードを返す。

• MTU サイズに注意を払う
理由は Path MTU ディスカバリが動作しないことが多いためである。

9

4.2.3 プロトコル仕様上変換できないプロトコルに対するアドレス変換

camp-net では Linux Debian squeeze (kernel 2.6.32)
64bit を用いて構築した。以下、Linux Debian squeeze(kernel 2.6.32) 64bit での設定である。

IPSec や FTP など、いくつかのプロトコルは、その仕様上 IPv4/IPv6 変換が行えない。しかしながら、これらの問題はサーバ側が IPv6 対応すれば簡単に解決す7.1

る問題なので、無理に変換する仕様を研究したり RFC

NAT64 implementation (linuxnat64) の入手で標準化する必要はない。

http://sourceforge.jp/projects/
sfnet linuxnat64/ か ら 図 7.1 に 示 す コ マ ン

5 おわりにドで入手できる。

ここでは、2011 年 9 月 WIDE 合宿にて実施した IPv6
only アクセス環境の検証実験に関して報告した。検7.2

証結果は AWFIT2011 [25] での発表論文やや IETF 82

linuxnat64 のコンパイル

図 7.2 に示すように、linux kernel source を apt-get コ

TAIPEI [26] でのインターネットドラフトで文書としマンドで入手し、次に linuxnat64 の作業ディレクトリ

てまとめ発表し、Global IPv6 summit TAIPEI や Inter-に移り make コマンドでコンパイルを実行する。

net Week の BoF で口頭発表を行った。発表した結果、WIDE プロジェクト内外から追検証を行ってほしいという要望が多く上がったため、2012 年 3 月 WIDE 合宿で

7.3“Life with IPv6 ワークショップ” としてワークショップを

linuxnat46 の設定

まず IPv6 および IPv4 prefix を単一の物理インター

開催し、より工学的な観点から 2011 年 9 月 WIDE 合宿

フェース（例えば eth0）に設定する。camp-net ではローで実施した実験の追検証を実施する運びとなった。2012

ドバランスを行うため nat64 を 3 台用意した。ここで年 3 月 WIDE 合宿での “Life with IPv6 ワークショップ”

は、3 台のうちの一つを例として記載する。NAT64 のにおける検証結果は来年度の WIDE 報告書や国内外の物理インターフェース（eth0）には以下のアドレスを

会議、標準化会議などで発表したい。

割り当てた。
!

2001:200:0:ff81::37/64

6 謝辞

"

203.178.158.37/26#$
次に DNS64 が A 応答で入手した IPv4 アドレスをWIDE プロジェクト 2011 年 9 月合宿に参加し実験にご協力頂いた全ての参加者、および実験環境の一部

IPv6 アドレスに格納してユーザに通知するために使われるアドレス変換用のプレフィックスを用意する。

として StarBED3 ・JGN-X の環境から資源提供してい
ただいた情報通信研究機構テストベッド研究開発推進

camp-net では次のプレフィックスををアドレス変換用

センターおよび北陸 StarBED 技術センターに感謝の意

プレフィックスとして用いた。
!

をここに示す。

2001:200:0:ff99::/96"

203.178.159.24/30#$
そして、図 7.3 に示すように linuxnat64 のカーネル

7 付録: ISC bind 9.8 と linuxnat64を用いた DNS64 / NAT64 の設定例

モジュールを起動し、仮想インターフェース（nat64）

ここでは、付録として、camp-net における ISC bindに next hop の設定を設定する。

9.8 と linuxnat64 を用いた DNS64 / NAT64 の設定例を記載する。英語による設定例は文献 [27] を参照していに図 7.3 に示すような形式でアドレス変換プレフィッ

ただきたい。

クスを NAT64 へ向けるスタティックルートの設定を投

最後に、バックボーンルータ（ここでは cisco ルータ）

10

参考文献

入する。この設定は rc.local 等に記載して再起動時に自動的に設定されるようにしておく。

[1] Y. Ueno. v6tun. git://quina.sfc.wide.
ad.jp/git/v6tun.git.

7.4

ISC bind の入手とコンパイル[2] University of Tsukuba and SoftEther Corporation.
UT-VPN. http://utvpn.tsukuba.ac.jp/.

bind 9.8 以降のソースコードを入手し、bind のマニュアルに沿ってコンパイルする。apt から入手できる bind[3] Internet Systems Consortium. DHCP. http://のバージョンが 9.8 以降であれば apt でバイナリを入www.isc.org/software/dhcp.

手しても構わない。

[4] X. Li, C. Bao, and F. Baker. IP/ICMP Translation

7.5

Algorithm. RFC 6145 (Proposed Standard), Aprilbind の設定

2011.

まず、bind のマニュアルに沿って設定ファイルを作成[5] M. Bagnulo, P. Matthews, and I. van Beijnum. State-する。次に、named.conf に次の設定を追加する。dns64

ful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. RFC 6146の次に記入している IPv6 アドレスプレフィックスはアドレス変換用アドレスプレフィックスである。設定するネットワーク環境に合わせて変更して欲しい。
!

dns64 2001:200:0:ff99::/96 {"(Proposed Standard), April 2011.
[6] M. Bagnulo, A. Sullivan, P. Matthews, and I. van
Beijnum. DNS64: DNS Extensions for Network
Address Translation from IPv6 Clients to IPv4
Servers.
2011.

clients { any; };mapped { any; };suffix ::;[7] Internet Systems Consortium. BIND. http://

recursive-only yes;

www.isc.org/software/bind.

};#

RFC 6147 (Proposed Standard), April[8] NLnet Labs.
$

そして、named-checkconf コマンドで named.conf の

syntax error を確認する。syntax error がないことが確

Unbound.

http://unbound.

net/.
[9] Viagénie.
Ecdysis: open-source implementation of a NAT64 gateway. http://ecdysis.
viagenie.ca/index.html.

認できたら rndc によって bind の再起動を行う。再起
動後、動作確認を行う。DNS64 をリゾルバとして設[10] Geeknet, Inc.
Linux NAT64 implementation.
http://linuxnat64.sourceforge.net/.

定し、適当な IPv4 アドレスのみ設定されたサーバのURL を名前解決した結果がアドレス変換プレフィック
スの IPv6 アドレスで返されると成功である。上記の[11] N. Lutchansky. TAYGA Simple, no-fuss NAT64 forLinux. http://www.litech.org/tayga/.

設定の場合、2001:200:0:ff99::xxxx:yyyy が返されることになる。名前解決によって返されたアドレスに対し[12] N. Matsuhira.

ping6 で応答が返ってきた場合、NAT64 も動作していMotivation for developing

Stateless Automatic IPv4 over IPv6 Tunneling (SA46T), Jul. 2011.
individual draft

る事が確認できる。

draft-matsuhira-sa46t-motivation-00.
txt.

11

[13] N. Matsuhira.
Applicability of Statewide-confidential/camp/11autumn/
less automatic IPv4 over IPv6 Tunnelenquete/result.cgi.
ing (SA46T), Jul. 2011.
individual draft[23] J. Arkko and A. Keranen. Experiences from andraft-matsuhira-sa46t-applicability-02.
IPv6-Only Network, Apr. 2011. individual draft
txt.
draft-arkko-ipv6-only-experience-03.
[14] N. Matsuhira.
Stateless Automatic IPv4
txt.
over IPv6 Tunneling:
Global SA46T Address Format, Jul. 2011.
individual draft[24] Y. Morishita and T. Jinmei. Common Misbehavior Against DNS Queries for IPv6 Addresses. RFC
4074 (Informational), May 2005.

draft-matsuhira-sa46t-gaddr-03.
txt.

[25] H. Hazeyama, Y. Ueno, H. Sato, Y. Yamagishi,
T. Yokoishi, and H. Ishibashi. How much can[15] N. Matsuhira. Stateless Automatic IPv4 over IPv6
Tunneling: Specification, Jul. 2011. individual draft

we survive on an IPv6 network? - Experience on

draft-matsuhira-sa46t-spec-03.txt.
[16] C. Charnsripiny, P. Tantatsanawong, and T. Sribud-

the IPv6 only connectivity with NAT64/DNS64 at
WIDE camp 2011 autumn. In Proceedings of Asia

dee. Research Network Infrastructure to Support
Future Internet Technology in Thailand, Aug.

Workshop on Future Internet Technologies (AWFIT2011), November 2011.

2011. Presentation in APAN 32nd meeting http:[26] H. Hazeyama and Y. Ueno. Experiences from an//www.apan.net/meetings/India2011/
Session/Slides/fit/3-2.pdf.

IPv6-Only Network in the WIDE Camp Autumn
2011, November 2011. http://tools.ietf.org/html/[17] Ed. R. Despres, S. Matsushima, T. Murakami,

draft-hazeyama-widecamp-ipv6-only-experience-and O. Troan.
IPv4 Residual Deployment
across IPv6-Service networks (4rd) ISP-NAT’s

00.
[27] Y. Ueno and H. Hazeyama.

made optional, Mar. 2011.
individual draft
draft-despres-intarea-4rd-01.txt.

NAT64 and DNS64 on ubuntu.

wide memohttps://member.wide.ad.jp/wide-confidential/memo/
wide-memo-camp1109-hack-eden-nat64-dns64-[18] masakazu’s Weblog. Vyatta で 4rd 環境を構築しよう. http://bougaidenpa.org/masakazu/

settings-00.txt.

archives/176.
[19] M. Oe, H. Hazeyama, S. Yamamoto, and S. Shirahata. An implementation and verification of ieee802.11 wireless network management system. Electronics and Communications in Japan (Part I: Communications), Vol. 88, No. 12, pp. 20–28, June 2005.
[20] StarBED Project.

How to setup

http://www.starbed.

org/.
[21] WIDE Cloud Working Group. WIDE Cloud Controller. http://wcc.wide.ad.jp/.
[22] WIDE Project. 2011 年 9 月 WIDE 合宿 アンケート
集計結果. https://member.wide.ad.jp/12

2001:200:0:ﬀ95::/64
2001:200:0:ﬀ95::/64
203.178.159.36/30

tunnel.fujisawa
tunnel.fujisawa

4rd-GWcisco14.fujisawa

WIDE
Backbone

2001:200:0:ﬀ30::/64

2001:200:0:ﬀ94::/64

cisco14.fujisawa

WIDE
Backbone

IPv6
INTERNET

2001:200:0:ﬀ94::/64

IPv6
INTERNET

Satellite
2001:200:0:ﬀ96::/64

Satellite/48 Preﬁx Delegation

2001:200:0:ﬀ96::/64

ONU

ONU

/64 Router Advertisement

HGW

SEIL

/56 Preﬁx Delegation/64 Router Advertisement

tunnel.core

tunnel.core

2001:200:0:ﬀ95::/64

2001:200:0:ﬀ95::/64

rtr.core

rtr.core

2001:200:0:ﬀ90::/64

2001:200:0:ﬀ90::/64(a) 合宿ネットワークバックボーン構成（9月 6 日 午後 8 時まで）

IPv6
INTERNETSpace
Satellite::2.5vlan 950
ﬀ95::/64
159.8/30

vlan 930
2409:150:9ﬀf::/48::2vlan 210
ﬀ21::/64::2.1::1 ::1::1・widecamp-sate- NAT64/DNS64

・widecamp-iij

・widecamp-4rd

Wi-Fi Preﬁx Information

・widecamp・widecamp-a
・widecamp-nowep- NAT64/DNS64

192.168.1.0/24(b) 合宿ネットワークバックボーン構成（9月 6 日 午後 8 時以降）

WIDE CAMP 2011 Autumn@Matsushiro 2011/9/15

vlan 960
ﬀ96::/64
159.4/30/64 Router Advertisement

4rd-CEESSID

vlan idwidecamp-4rd

500

widecamp-sate

600 2001:200:0:ﬀ60::/64

preﬁx

widecamp-iij

880

widecamp
2001:200:0:ﬀ90::/64
widecamp-a
900203.178.156.0/24
widecamp-nowep(c) 合宿ネットワークアクセス周りの構成

図 1: 合宿ネットワークの構成

13

(a) 参加者が利用したと申告したユーザア
クセスの割合(b) Q1: 今回の合宿では主に IPv6 のみを提供しましたがいかがでしたか？

(c) Q2: 今回のネットワークの品質はいかがでしたか？

(d) Q3: SSID:widecamp において IPv4 の認証サービスを使いましたか?

図 2: NOC による実験のアンケート結果

14

(a) Q4: SSID: widecamp-4rd を使いましたか？

(b) Q5: widecamp-4rd の通信環境上での通信はいかがだったでしょうか?
(Web)(c) Q6: widecamp-4rd の通信環境上での通信はいかがだったでしょうか?
(Mail)(d) Q7: widecamp-4rd の通信環境上での通信はいかがだったでしょうか?
(VPN)(e) Q8: widecamp-4rd の通信環境上での通信はいかがだったでしょうか?
(Messenger)(f) Q9: widecamp-4rd の通信環境上での通信はいかがだったでしょうか?
(SSH)

図 3: 4RD 検証実験のアンケート結果!

"#git clone git://linuxnat64.git.sourceforge.net/gitroot/linuxnat64/linuxnat64#$
図 4: git による linuxnat64 の入手!

#apt-get install linux-headers-’uname -r’"#cd <your_working_dir>/linuxnat64/modules/
#make
#

$
図 5: linuxnat64 のコンパイル15!

# insmod /path/to/nat64.ko ipv4_address=203.178.159.25 \prefix_address=2001:200:0:ff99::"# ip link set nat64 up# ip -6 route add 2001:200:0:ff99::/96 dev nat64# ip route add 203.178.159.24/30 dev nat64#$

図 6: linuxnat64 の起動と設定!

ipv6 route 2001:200:0:FF99::/96 2001:200:0:FF81::37"

ip route 203.178.159.24 255.255.255.252 203.178.158.37#$
図 7: cisco ルータでの NAT64 へのスタティック経路の設定

16