Tunnel Broker で IPv6 を試してみる

その他

NTT 東日本がフレッツ光ネクストで 2011年7月に IPv6 IPoE のサービスを始めてかれこれ 10年以上が経っている。Google の統計によると、日本国内でも今日現在で約 50% が IPv6 で Google にアクセスしているそうだ。

ところが自分の住んでいる地域はフレッツ光のサービス提供時期がいつまでたっても未定のままなので、今はケーブル光インターネット(1G)を利用している。実際のところ、コンスタントに上り下りとも 600Mbps 程度が出ているから不満はない。何なら 10G サービスにすることもできるから通信速度が問題になることはなさそう。

それよりも、IPv6 が普及しつつあるなか、ケーブルテレビ会社は IPv6 の割り振りを受けた指定事業者ではあるものの、接続に関するアナウンスは何もないから、とりあえず雰囲気だけでも感じてみようということで、Hurricane Electric Free IPv6 Tunnel Broker を試してみることにした。

 

前提

フレッツ光ネクストのような快適さを求めるものではない。Hurricane Electric Free IPv6 Tunnel Broker は IPv6 のパケットに IPv4 のヘッダを付けてカプセル化する仕組みで、実験・開発者を対象とされている無料のサービス。
日本国内にもサーバー(トンネルの接続先)はあるものの、レイテンシは次のとおり通常(IPv4)の 10倍くらいかかっているから、あくまでもお試しということで。

$ ping6 google.com
PING google.com(nrt20s09-in-x0e.1e100.net (2404:6800:4004:80b::200e)) 56 data bytes
64 bytes from nrt20s09-in-x0e.1e100.net (2404:6800:4004:80b::200e): icmp_seq=1 ttl=119 time=138 ms
64 bytes from nrt20s09-in-x0e.1e100.net (2404:6800:4004:80b::200e): icmp_seq=2 ttl=119 time=131 ms
64 bytes from nrt20s09-in-x0e.1e100.net (2404:6800:4004:80b::200e): icmp_seq=3 ttl=119 time=152 ms
64 bytes from nrt20s09-in-x0e.1e100.net (2404:6800:4004:80b::200e): icmp_seq=4 ttl=119 time=146 ms
64 bytes from nrt20s09-in-x0e.1e100.net (2404:6800:4004:80b::200e): icmp_seq=5 ttl=119 time=153 ms

$ ping google.com
PING google.com (142.251.222.46) 56(84) bytes of data.
64 bytes from nrt13s72-in-f14.1e100.net (142.251.222.46): icmp_seq=1 ttl=118 time=11.5 ms
64 bytes from nrt13s72-in-f14.1e100.net (142.251.222.46): icmp_seq=2 ttl=118 time=20.0 ms
64 bytes from nrt13s72-in-f14.1e100.net (142.251.222.46): icmp_seq=3 ttl=118 time=20.1 ms
64 bytes from nrt13s72-in-f14.1e100.net (142.251.222.46): icmp_seq=4 ttl=118 time=11.7 ms
64 bytes from nrt13s72-in-f14.1e100.net (142.251.222.46): icmp_seq=5 ttl=118 time=19.8 ms

 

Tunnel Broker の特徴

  • 実験用としてグローバルユニキャストアドレス(IPv4 におけるグローバルアドレス)を利用できる。
  • /48 プレフィックスを取得可能。自鯖環境に IPv6 Router を設置して色々試すことができる。
  • Debian/Ubuntu や FreeBSD、Mac OS X その他、様々な設定サンプルがあって便利。
  • NAPT の内側の VM を Client にすることができるから、Proxmox VE のクラスタで色々お試し可能。
  • 自宅の WAN 側のアドレスが変わったら、DDNS のように接続情報を更新する必要がある。

 

アカウントの登録と設定

親切な記事があるから詳細はリンク先「IPv6 Tunnel Brokerを使ってIPv6ネイティブな環境を構築する」や「YAMAHAルーターでIPv6 over IPv4サービスを使う」をご覧ください。

登録が終わったら、画面の情報に基づいて Client に IPv6 のグローバルユニキャストアドレスを割り当てる。
自分の場合(Debian)は /etc/network/interfaces にサンプル設定をコピペして、local のアドレスを VM のアドレスにすれば大丈夫だった。

注意するところとしては、NAPT の内側を Client とする場合、自宅のルーターの「protocol 41 の開放」を忘れずに行うこと。「port 41 の開放」ではありません。

登録情報によると、自分は Debian の VM を用意して、まずは 2001:db8:11:11::2/64 のようなアドレスが割り当てられることとなった。サーバー(Gateway)のアドレスは 2001:db8:11:11::1/64 。

上の 2001:db8::/32 は文書用のアドレス。
実際には Tunnel Broker の画面情報をもとに設定すること。

外部から ping6 を実行するには SubnetOnline.com が便利。

 

YAMAHA RTX830 のプロトコル開放

管理画面>詳細設定>NAT から適用しているNATディスクリプターの右端「設定」をクリックする。
表示された画面の下側に「静的IPマスカレードの設定」から、ポート開放なら「識別番号」「内側アドレス」「プロトコル」「ポート番号」にそれぞれ必要事項を記入するところ、今回はプロトコル開放だからポート番号の欄は空白とする。
併せてプロトコルの欄を「ipv6」とすることで、外部(インターネット)から WAN 側のインターフェースを通過するパケットを内部アドレスに変換(開放)することができる。

protocol 41 は tcp/udp を使用しません(Wikipedia より)

 

次の記事(予定)

とりあえず /64 のグローバルユニキャストアドレスを取得できたから、例えば Apache Web Server の動作している VM に 001:db8:22:22::11/64 などを付与すればインターネット上に公開することは可能。ただし、ufw をきちんと設定しないと無防備だから、まだまだ準備することがある。

他にも、MyDNS への登録や、自宅のグローバル IP が変わったときの自動更新スクリプトなどなど、色々試してみたいことがあるから少しずつメモを残していこう。

タグ