EC2インスタンスからIPv6

AWSのElastic Load BalancerはIPv6のエンドポイントも持ってるので、たいていの場合はそれで用が足りるのかもしれませんが、やはりノードにはIPv6アドレスをつけたいこともあるかと思います。
とりあえずトンネルでも張るしか無いのが現状なのですが、AWSのSecurity Group (Firewallのようなものと思って下さい)にはICMPとTCPとUDPしか設定項目にありません。
せっかく固定グローバルアドレスを取れるので、ip proto 41を使ってトンネルを張りたいと思っても一見無理です。

が、やってみたら実は出来ることがわかりました。
内部から外向けにパケットをそれなりの感覚で流している限り、TCP, UDP, ICMP以外のプロトコルもNATテーブルには残してもらえるようです。

つまり、Hurricane Electricや、SixXSのようなトンネルブローカーにお世話になれば、EC2インスタンスにもIPv6の到達性を提供出来ます。

ただ、一点つまづく点が。
どうにもこうにも、Hurricane Electricのトンネルでパケットの送信は出来るものの、受信が出来ません。
トンネルインターフェース上でff02:1にpingを打つと対向から返事があるので、トンネルとしては機能しているのですが。
SixXSでは動くので、いいと言えばいいのですが、出来れば日本に終端点のあるHurricane Electricを使いたいところ。
現在この件、サポートに問い合わせ中です。

ubuntu@ip-10-162-51-149:~$ ifconfig
~~~~~
he-ipv6 Link encap:IPv6-in-IPv4
inet6 addr: fe80::aa2:3395/128 Scope:Link
inet6 addr: 2001:470:23:XXX::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:208 (208.0 B) TX bytes:728 (728.0 B)

~~~~~

sixxs Link encap:IPv6-in-IPv4
inet6 addr: fe80::aa2:3395/128 Scope:Link
inet6 addr: 2401:e800:YYY:ZZZ::2/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:23 errors:0 dropped:0 overruns:0 frame:0
TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7012 (7.0 KB) TX bytes:7012 (7.0 KB)

ubuntu@ip-10-162-51-149:~$ ping6 2001:470:23:XXX::1
PING 2001:470:23:XXX::1(2001:470:23:XXX::1) 56 data bytes
^C
--- 2001:470:23:XXX::1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4031ms

ubuntu@ip-10-162-51-149:~$ ping6 2401:e800:YYY:ZZZ::1
PING 2401:e800:YYY:ZZZ::1(2401:e800:YYY:4::1) 56 data bytes
64 bytes from 2401:e800:YYY:ZZZ::1: icmp_seq=1 ttl=64 time=88.4 ms
64 bytes from 2401:e800:YYY:ZZZ::1: icmp_seq=2 ttl=64 time=88.7 ms
^C
--- 2401:e800:100:4::1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 88.401/88.595/88.789/0.194 ms
ubuntu@ip-10-162-51-149:~$ ping6 -I he-ipv6 ff02::1
PING ff02::1(ff02::1) from fe80::aa2:3395 he-ipv6: 56 data bytes
64 bytes from fe80::aa2:3395: icmp_seq=1 ttl=64 time=0.040 ms
64 bytes from fe80::4a52:2e06: icmp_seq=1 ttl=64 time=3.27 ms (DUP!)
64 bytes from fe80::aa2:3395: icmp_seq=2 ttl=64 time=0.052 ms
64 bytes from fe80::4a52:2e06: icmp_seq=2 ttl=64 time=3.31 ms (DUP!)
64 bytes from fe80::aa2:3395: icmp_seq=3 ttl=64 time=0.059 ms
64 bytes from fe80::4a52:2e06: icmp_seq=3 ttl=64 time=3.07 ms (DUP!)
^C
--- ff02::1 ping statistics ---
3 packets transmitted, 3 received, +3 duplicates, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.040/1.634/3.314/1.586 ms
ubuntu@ip-10-162-51-149:~$

Flets v6とIPv6インターネットの共存

IPv4アドレスの枯渇、Bフレッツ上でのIPｖ６接続サービスに関する昨今の俄な動きで何かとIPv6が話題(?)ですね。
こんなブログに足を運ぶ皆様におかれましては、おそらくとうの昔からIPv6コネクティビティは確保されていて、ここに今日書こうとする内容など今更、といったことでしょうが、意外とネット上に情報がないように思えたので念の為。

我が家は学生時代より、今思えばおおよそ7, 8年前から、トンネルではあるもののIPv6コネクティビティを確保してきましたが、ここ最近、某社のNGNサービスが始まって以来、トラブルに見舞われることが多くなってきました。

というのも、NTTのNGNサービス（Flets NEXTだっけ？）開始以降、Bフレッツにつなぐと、NGN向けのルータからRouter Advertisement (RA)が来てしまうのです。
適切なRAならご親切にルーティング情報をありがとう、というところなのですが、NTTのNGNはあくまで閉域網、いわゆるWalled Gardenサービスなので、あくまでNTTが提供するコンテントサーバへのアクセスを提供するためのネットワーク。
よって、そちらにインターネット行きのパケットなど送ろうものなら、容赦なく破棄されてしまいます。

これがどういうことかというと、IPv6に対応したホストをBフレッツにつなぐとあら大変、IPv6のルーティング情報をかき乱して、場合によっては（結構多くの場合）、IPv6のパケットを吸い込むブラックホールとして機能してくれてしまうのです。
（まあ親切にTCP Resetを送ってくれるのでタイムアウトは速いみたいですが）

「ふーん、でもIPv6なんて使ってないから関係ないや」と仰る方もいらっしゃるかもしれませんが、そういう方にもこの問題は対岸の火事ではありません。
最近のOSの多くはIPv6に対応しているので、知らないうちにNTTから配布されるNGN向けのアドレスとルーティング情報を受け取ってしまっていたりします。
その状態でblog.ameba.jpのようないわゆるホスト名をDNSを使って名前解決した結果、仮にIPv6のアドレス（AAAAレコード）が返ってきたりしてしまうと、そのアドレスに一生懸命接続を試み、ブラックホールに吸い込まれるという事態に陥ります。
（さっきも言ったように、タイムアウトが速いように工夫されているのでダメージはそこまで大きくありませんが、それでもアクセスのレイテンシは上がります。実際、某NTT系ISPのFAQでも、IPｖ６をOFFにしましょうという横暴なガイドラインが出されています。）

これはいわゆるNon Congruent Multi Homingな環境での典型的な問題なので、多くの問題提起がなされているのですが、Endユーザの手を煩わせずに解決する手段が意外とないのが現状です。
一番手っ取り早い解決は、ゲートウェイのところでRAを受け止めてクライアントに流さないようにしてしまうことです。
NTT NGN上のコンテンツを利用するつもりがハナからない私のような人にはこれでも十分な解決法になり得ます。

ただ、通常NTTが配布するホームゲートウェイなどではこんな設定はできないようですし、時々でもNGNにもアクセスしたいという気がある場合にはこの手段は取れません。
（私の場合、どちらかというと、アクセス出来るものはシームレスにアクセスできないと気が済まないというのが動機で上記の手は止めました。実際にアクセスすることはほぼ皆無なんですけど。）

上記の設定下でもやっぱりNTT NGNへのアクセスは捨てたくないという場合、考えるのはNATでしょうか。（いわゆるNAT66）
RAをゲートウェイで受け止めてしまえば配下のホストからのパケットは全部ゲートウェイに向かうので、インターネットへもフレッツへも足を持つゲートウェイでルーティングをすればよいのですが、パケットを転送する際、ソースアドレスを宛先によって切り替えない限り、NTT NGN向けにインターネット上のIPアドレスをソースにパケットを送ってしまったらその後二度と返ってこれません。
（何故か？坊やだからではなく、NTT NGNはあくまで閉域網だから。。。）

そこで、ゲートウェイでNATして、宛先に応じてソースを書き換えてやればいいじゃないかと話が上でNATが出てきた理由です。
が、しかし、せっかくNATなしでもアドレスが足りなくならないIPv6なのにNAT？という疑問に代表されるように、これまでこの話は議論に上がりつつも、実際のソリューションとしては避けられてきていて、実装もあまり見当たりません。
（個人的にはひとつの解決法としてありかと思います。これが一番ゲートウェイ配下のホストに手を加えずに住む方法という意味で優れているし。）

それ以外の方法となると、真面目に、実直に、各ホストのルーティングテーブルの調整と、アドレス選択アルゴリズムのパラメータを調整する、という話になってくるのが現状です。
というわけで長かったですが、ここまでが前置き、この後の短いのがこの記事の本題です。
以下はNTT NGNとIPv6インターネットのマルチホーミングなネットワークに接続されたホストで、適切に両方のネットワークにアクセスできるようにするための一設定です。（Ubuntu/Debian系 Linuxの場合）

こんなスクリプトを適切な箇所で読んであげると、おおよそのケースは解決できると思います。
--------fletsconfig.sh------------
#!/bin/sh

# Prefix assigned for your home gateway (copy from output from e.g. ifconfig)
MY_FLETS_PREFIX=2001:db8::/64
# Interface connected to your lan that is connected to both NTT NGN and IPv6 Internet
INTERFACE=eth0
# Link local address of your IPv6 Intenet gateway
INTERNET_GATEWAY=fe80::20e:7bff:feXX:XXXX
# Link local address of your NTT NGN gateway
FLETS_GATEWAY=fe80::21f:67ff:feYY:YYYY
# Arbitrary number for prefix label (choose a non-conflicting value with seeing the output from 'ip addrlabel show')
FLETS_ADDRLABEL=10

# Adjusting routing table
route -A inet6 add ::/0 gw $INTERNET_GATEWAY dev $INTERFACE metric 768
route -A inet6 add 2404:1a8::/32 gw $FLETS_GATEWAY dev $INTERFACE metric 512
route -A inet6 add 2001:c90::/32 gw $FLETS_GATEWAY dev $INTERFACE metric 512

# label for flets
ip addrlabel add prefix $MY_FLETS_PREFIX label $FLETS_ADDRLABEL
ip addrlabel add prefix 2001:c90::/32 label $FLETS_ADDRLABEL
ip addrlabel add prefix 2404:1a8::/32 label $FLETS_ADDRLABEL
------------------------------------

2001:c90::/32と2404:1a8::/32はNGN上で使われているとおぼしきアドレス（の一部）です。
この他にもあれば追加する必要があります。
が、とりあえずflets-east.jpならこれでも良さそうな感じがしています。

簡単に説明すると、Adjusting routing tableと書かれた箇所で、ルーティングテーブルに、デフォルトより小さなメトリックで$INTERNET_GATEWAYをデフォルトルートとして、$FLETS_GATEWAYをさらに小さなメトリックでNGNで使われるアドレスセグメントへの経路として設定しています。
これだけで十分に思えるかもしれませんし、実際、www.kame.netなどをひらいてみると亀が動いていたりして、満足してしまうケースもあるかもしれません。

IPv6への接続が道楽である時代にはここまででも十分だったかもしれないのですが、昨今はそうも一定られません。
なぜなら、実際には上記のような経路情報の設定のみだと、ソースアドレス選択で問題が生じ、特定のサイト、しかも重要なサイトにアクセスできなかったりします。

IPv6の仕様では、インターフェースが複数のアドレスを持つとき、特に追加設定がない限り、多くの場合、宛先のアドレスと最も長くマッチするPrefixをもつアドレスがソースアドレスとして選択されます。
すなわち、インターフェースに2001で始まるアドレスと2408でアドレスが付いていたとして、2404で始まるアドレス宛にパケットを送ろうとした場合、宛先のネットワークがどうということに関係なく、2408で始まるアドレスの方が選ばれてしまいます。（なぜなら、2404と2408の方が2001に比べてより長くPrefixがマッチするから）

これが実際にどのくらいに問題になるかというと、おそらく多くの人が日常的にアクセスするであろうサイトにpingを打ってみたりすると気づきます。
（試しに、ping ipv6.google.comなどとしてみると。。。）

# label for fletsと書かれた箇所がこの問題をアドレスします。
この箇所の意味はちょっと直感的に分かりにくいかもしれませんが、NTT NGNで割り当てられるPrefixのセグメントと、NGN内で使われている（であろう）アドレスセグメントに同一のアドレスラベルを割りあて、一つのグループとしてみなすように、アドレス選択アルゴリズムに指示を出すことを意味します。
すなわち、Prefixのマッチングに優先して、「これらは一つのグループだからこれに基づいてソースアドレス選択をして」という指示をアルゴリズムに与えることになります。（See RFC3484）

この結果、NGN向けのアドレスの付いたパケットの送出を請け負ったホストOS君は、宛先とルーティングテーブルを見ながらまず転送に使うインターフェースを決定し、さらにそのインターフェースについているアドレスの中から同じラベルの付いたアドレスを選び出してソースアドレスに設定するという動作を行うことになります。
すなわち、インターネット向けにはインターネット上のアドレスをソースに、NGN向けにはNGN上のアドレスを、という具合に。

それにしてもこういう設定もRAかDHCPか何かで配れるようにならないときついですね。
World IPv6 Dayも近づく中、どうするどうなる日本のインターネット。

WebとDLNAデバイスが繋がる

Ericsson LabsがWebの世界とDLNAの世界をつなげるAPIを公開しました～。

何ができるかというと、YoutubeやUstのページ上で、Bookmarkletから自分のデバイスのリストを呼び出して、気になるビデオのリンクをDLNA DMR対応のTVにDrag ＆ Dropして再生といったことや、外出先から家のNASをブラウズしてコンテンツを再生したり、家のNASのコンテンツを出先のDLNA DMR対応のTVに出したりといった使い方がデモされてます。



うーん、エコポイント半減の前にやっぱりソニーのLEDになる直前のモデルで値下がりしたやつを買っとくべきだったかな。
40インチでDLNA DMR対応、7万円弱でエコポイント23,000はやっぱり魅力だったかも。。。