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

IPv4アドレスの枯渇、Bフレッツ上でのIPv6接続サービスに関する昨今の俄な動きで何かと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でも、IPv6を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も近づく中、どうするどうなる日本のインターネット。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中