Home

IPv6導入記

【お知らせ】
「IPv6勉強会」コミュニティを作りました。興味がある方はメンバー登録してくださいね (^^)/

続編の「光 NEXT & IPv6 PPPoEへの道」ってのもあります

拙宅のネットワーク環境(ちょいとした企業クラスのネットワーク構成)に IPv6 を導入した時の試行錯誤を徒然なるままに書いた雑記です。
これから IPv6 を導入しようと考えている方に何かしらのヒントになればと書いてみました。

ちなみに、2009/03/28 に京都でスピーカーをした「京都 IPv6 勉強会 ～これからどうすればいいのか？～」との連動も意識しており、当日使用したスライドもこちらからダウンロードできます。

スライドを自社の講習会やその他資料等への二次利用 OK ですし、事実と相違が無い範囲で改変して使用していただいても構いません。
ただ、著作権は放棄したくないので、このスライドを二次利用する際は、著作権者(村嶋修一 or MURA)と著作権者の Web サイト URL(http://www.vwnet.jp)を小さくて構わないで何処かに明記してください。
二次利用に際して、当方への連絡は不要です。

ちなみに、pptx はプライベート発行の証明書で署名していますので、改変する際は署名を削除してください。

>>> IPv6_in_kyoto.pptx ( 2.3MB ) <<<
>>> IPv6_in_kyoto.pdf ( IPv6_in_kyoto..zip/3.7MB ) <<<

とりあえず、お手軽(?)にスライドを見たい方はこちら(スライドを PNG にしてベタに並べてみました)

2009/12/12 に 第18回 Admintech.jp 勉強会で「これから始めるIPv6 ～Windows編～」って話をしましたので、その資料もこちらで公開します。こちらの資料の扱いも京都IPv6勉強会の資料と同じです。

>>> AdminTech-IPv6_pptx.zip (1.5MB) <<<
>>> AdminTech-IPv6_pdf.zip (2.7MB) <<<
>>> AdminTech18-Videos.zip (9.2MB) <<<

オンラインでスライドを見たい方はこちらをどうぞ(当日使用したビデオもオンラインで見られます)

きっかけ

なぜ拙宅に IPv6 を導入しようかと思ったかと言うと... 話は簡単で、Windows Server 2008 の本を書くための検証材料にしたかったからです。(2009/06発売)
Windows Server 2008 と Vista は IPv6 の正式サポートした証である「IPv6 Ready Logo Program Phase-2」の認定を受けた OS です。丁度「IPv4 アドレス枯渇問題」も話題になり始め、これから IPv6 が注目されると予想して、一足先に「現場での IPv6 はどのように導入するのが良いのか」って検証も兼ねて IPv6 の導入を決意しました。

RFC を読んだり、テクニカルセミナーの話を聞いていると「運用と管理を可能な限り省力化するのが IPv6 の本質」と僕は感じたので、基本路線は「省力化」に照準を合わせました。
「本質」って表現は言いすぎかもですが、省力化の仕組みが用意されているので、それらをフル活用して日常の運用と管理は楽をしようってアプローチです。(根が面倒くさがり屋ってのが多分にあるかも ^^;)

目論み

どうせ IPv6 を導入するのなら、内部ネットワークだけではなく、インターネットアクセスも IPv6 にしたいな。そこまでするのなら、インターネット公開サーバも IPv6 でアクセスできるようにしたいので、グローバル IPv6 アドレスである GUA を取得しまた。
実は、これが2つ目の GUA で、最初に GUA を取得したのは、IPv6 のテスト運用が開始された頃です。当時はテスト評価が条件で無償で GUA 取得ができていました。その GUA も ISP の契約変更をしたので使う事が出来なくなってしまいましたが、これを書いている時点で登録そのものはまだ生きていました。
今回契約した GUA は、商業ベースなので月額使用料が発生しますが、これも先行者の宿命と自分を納得させ、今でも月額使用料を払い続けています。

IPv6の再勉強

一応ネットワーク屋の看板を掲げているので、IPv6 を知らないって訳では無いのですが、RFC や 書籍で「読んだ事がある」程度で、構築もテストレベルのネットワークをちょこっと構築したくらいです。運用レベルの IPv6 ネットワークを構築した経験はありませんし、IPv6 の知識が十分あると言うわけでもありません。
もう一度 IPv6 を再勉強するかと RFC を読みなおし始めたのですが... IPv6 の勉強を初めてした当時に比べ、IPv6 関連の RFC が爆発的に増えていました。
ざっと眺めてはみたのですが... 英語が苦手なのも手伝って、各 RFC の関連性が見えてきません(泣)

これでは埒が明かないので、WIDE/JPNIC 主催(?)の IPv6 カンファレンスに参加してみましたが、ISP やメーカー向けの話ばかりで、「現場でどうするの?」って疑問に答えるものでは無かったです。
仕方がないので、IPv6 の書籍を買いあさったのですが、執筆陣がカンファレンススピーカーと同一人物の書籍が多かったので、ここでも答えを得る事は出来ず orz

後日、カンファレンス後にスピーカーをされていた方とコンタクトが取れて、現場への導入ノウハウについての意見交換をする事が出来ました。
そこで得た結論は、「現場導入ノウハウの必要性は十分感じているが、まだ提供できるだけのものが無い状態なので、これから作っていなくてはならない」って事でした。

「仕方がない、この人柱を買って出るか」ってのが今回の IPv6 導入目的でもあります。

一緒に購入したオライリーの「IPv6 エッセンシャルズ 第2版」が技術的な部分はカバーしてくれたので RFC で悩んでいた部分の大半を解消出来たのは収穫でした。

IPv6アドレス割り当て

まず決めなくてはならないのが、サイトで使用する IPv6 アドレス体系です。

色々調べて、サイトには/48を、各セグメントには/64のプレフィックスを使用するのはわかっていたし、IPv6 では NAT を使わない方針だって事もわかっていました。

GUA を取得したので、サイト内に GUA を割り当てれば、インターネットアクセスに NAT は不要になります。
ん? 待てよ? GUA を使うって事は、ISP の変更をした時はサイトで使用している IPv6 アドレスを全てリナンバしなくちゃならないじゃないか!! って事に気がつき.... (遅)
そうすると、IPv4 で言うところのプライベートアドレスを導入しなくちゃならないなと、RFC を読みあさっていたら、サイトローカルの仕様を発見。でも、このサイトローカルは既に廃止されて、RFC 4193 Unique Local IPv6 Unicast Addresses で再定義されていました。(以降 ULA)

RFC を読むと、「fc00::/7 + 計算結果」で /48 のサイトプレフィックスを生成せよとあります。もう少し調べると、fc00::/8 は IANA が予約しているので、実際に使用できるのは「fd00::/8」と言う事が判明。
ULA 計算のプログラムを書くのも面倒なので、インターネットで検索すると ULA 計算ページが複数ありましたし、Javaで書かれた計算ツールも見つけました。

Generate Unique Local Address(Kame Project)
http://www.kame.net/~suz/gen-ula.html

IPv6実験所(ULA 生成 JAR)
http://www.02.246.ne.jp/~torutk/ipv6/uniquelocal.html

ULA の生成も出来たので、GUA + ULA の2アドレス構成をサイトアドレス体系にする事にしました。

またまた余談ですが、Microsoft MVP Global Summit 2008 で MS 本社に行った時に、MS の開発エンジニアに「Windows の標準ツールとして ULA の算出プログラムを提供してほしい」ってリクエストしたのですが、既にインターネット上で複数提供されているので必要ないだろうって事で提案はボツに ^^;

IPv6 は IP アドレス自動構成が出来るので、さっそく自動構成できるように RA を手持ちの YAMAHA RTX1100 に設定。設定そのものは難しくありません。
Vista と Windows Server 2008 で ipconfig してみると、GUA と ULA が自動構成されていました。

# YAMAHA RT シリーズの IPv6 設定
ipv6 prefix 1 fd75:f582:7ae3::/64 ← RAするプレフィックス(ULA)
ipv6 prefix 2 2001:278:101d::/64 ← RAするプレフィックス(GUA)
ipv6 lan1 prefix fd75:f582:7ae3::/64 ← LAN1のIPv6アドレス構成(ULA)
ipv6 lan1 prefix 2001:278:101d::/64 ← LAN1のIPv6アドレス構成(GUA)
ipv6 lan1 rtadv send 1 2 ← RA実装

[IPv6アドレスの自動構成]

まずは成功 ^^v

インターフェイスID設定

Vista が自動構成した IPv6 アドレスは、匿名アドレスと呼ばれる動的な IPv6 アドレスで、インターフェイス ID(64ビットのサフィックス)がランダムに割り当てられ、デフォルト24時間毎に変更される仕様になっています。
クライアントはこれで良いのですが、サーバも匿名アドレスの体系になっています。ちょっと、この仕様はないんじゃないの? と調べたら、インターフェイス ID をスタティックである EUI-64 に変更するコマンド「netsh interface ipv6 set global randomizeidentifiers=disabled」を見つけました(正直に言うと、MS 中の人に教えてもらいました)

これで、サーバの IPv6 アドレスも固定できるので、自動構成に任すことができます。
実際にサーバを展開してみると、netsh コマンドを入力する必要はありますが、IPv6 の設定は何も要らないので楽ちんですね。IPv4 アドレスの設定が必要なのは変わりませんけど。

以前 MS に「Windows Server 2008 は EUI-64 のインターフェイス IDをデフォルトとすべきだ」とフィードバックしていたのですが...
Windows Server 2008 のインターフェイス ID は、体系こそ匿名アドレスだけど、実は静的に割り当てられているって事でした。つまり、IPv6 に関しては、netsh コマンドすら必要なくて、RA さえ設定できていれば完全にノンオペレーションで良いって事です。さらに楽ちん !!
LAN 側は、なんかのはずみで IPv6 アドレスが自動変更されても、ドメインコントローラの DDNS で追従できるので、この仕様でいけますが、DMZ 上 DNS はセキュリティの観点から自動化はしたくないので、DMZ 上のサーバは静的割り当てが保障されている EUI-64 がお勧めですね。

Windows Server 2008 のドメインコントローラ等の一部の役割は、EUI-64 にしても自動構成の IPv6 アドレスは受け付けないので、手動割り当てが必要だったりします。

Windows で IPv6 アドレスを手動で割り当てると、RA 環境では自動構成 IPv6 アドレスも出来てしまいます。これを手動設定 IPv6 アドレスだけにしたい場合はこちらを見てください。

DNSディスカバリー

IPv6 アドレスの自動構成が出来るようになったので、次は名前解決です。

まずは、IPv4/IPv6 デュアルスタックのドメインコントローラを構築して、AAAA が正常動作するか確認ですね。ドメインコントローラ自身の IPv6 アドレスは、自動構成の IPv6 アドレスを受け付けないので手動で設定します。参照 DNS は自分自身なので、ループパックである「::1」を設定して基本的な構成は完了。
DNS に IPv6 の逆引き参照ゾーンをを作って、手動で AAAA を登録し、ドメインコントローラ上で nslookup を使って動作確認をします。まぁ、当然のごとく正/逆引きとも問題なく動作しますね。

それでは、ドメインにメンバーサーバを追加しようと思った時に... あれ?、IPv6 の参照 DNS はどうするんだ?
RA では、参照 DNS を設定できないし... 手動で参照 DNS を設定すると省力化にならないので、DHCPv6 を使うか...

DHCPv6 は管理省力化重視でステートレスを選択しました。Windows Server 2008 の DHCPv6 もデフォルトがステートレスになっています。
さて、これで参照 DNS がセットされる筈と、ドメインにまだ参加させていない Windows Server 2008で ipconfig /all すると... あれ? 参照 DNS がセットされていない?

調べると、DHCPv6 を機能させるには RA でフラグコントロールをする必要があることが判明。今回はステートレス DHCPv6 なので、RA を喋らせている RTX1100 で 「Oフラグ」のオンの通知をするように設定すると、参照 DNS がセットされるようになりました。
ドメインにメンバーサーバを追加すると、DNS に AAAA と IPv6 の PTR も登録されますね。

# YAMAHA RT シリーズでのM/Oフラグコントロール
ipv6 lan1 rtadv send 1 2 o_flag=on ← RA実装で O フラグを ON

第二関門通過 ^^v

では、実環境に近付けるためにサーバセグメントとクライアントセグメントに分離したら、今度はクライアントセグメントに配置した Vista の IPv6 参照 DNS がセットされません。
そか、ステートレス DHCPv6 はリンクローカルにしか広告されないんだっけ。

また RFC を調べると、こいつの解決には DHCPv6 リレーをする必要がありそう。YAMAHA のルータは、IPv6 Ready Logo Program Phase-1 なので、DHCPv6 リレーエージェントは実装されていませんし、リレーが出来たとしても、運用が面倒だなと別の方法を模索開始。

色々思案した結果、DNS は、IPv4 で問い合わせをしても AAAA を引くことができるので、名前解決には IPv4 を、データ通信には IPv6 を使う方向で暫定回避させることにしました。

ちなみに、IETF でも DNS ディスカバリーは議論の対象になっており、RA で参照 DNS を広告する案に落ち着くのかなと予想しています。

インターネット接続テスト

拙宅のインターネット接続回線は、ソフトバンクテレコムの ULTINA Internet のブロードバンドアクセス フレッツ・プランで /29 の固定 IPv4 アドレス運用をしています。
IPv6 は、こいつのオプションで提供されている 6over4 のトンネリングサービスにしました。これ以外にもデュアルスタックとかネイティブとかの品目もあるのですが、とても個人で維持できる金額では無いですし ^^;

この環境でインターネットに IPv6 接続するためには、6over4 の ipip トンネルを張らなくてはいけません。このあたりのサンプルがほとんどなかったので、RTX1100 のマニュアルと試行錯誤で何とかトンネルを張りました。

[6over4ネットワーク]

# YAMAHA RT シリーズでの 6over4 トンネル
ipv6 route default gateway tunnel 1 ← IPv6 のデフォルトゲートウェイを 6over4 トンネルに向ける
tunnel select 1
 tunnel encapsulation ipip ← 6over4 の IPIP トンネル
 tunnel endpoint address 211.121.188.193 218.218.255.213 ← 6over4トンネルの両端(IPv4)
 ipv6 tunnel address 2001:278:0:221d::2/64 ← 6over4トンネルのこちら側 (IPv6)
 ipv6 tunnel tcp mss limit auto
 tunnel enable 1

IPv6 でインターネットアクセスデビューの瞬間です。

IPv6 ホストに対して、ping/traceroute をすると、宛先が IPv6 なので違いがわかるのですが、IPv6 は下位層の話なので Web ブラウザで見る分には違いはありませんね ^^;

[ping]

[tracert]

Web ブラウザで IPv6 でアクセスできているのかを確認するには、接続元の IP アドレスを表示するサイトに接続するのが一番手っ取り早いです。

What is my IPv6 Address?(接続 IP アドレス表示)
http://whatismyipv6address.com/

OCN IPv6 通信確認サイト(IPv4/IPv6 でアニメーションが違う)
http://www.ocnipv6.jp/

[IPv6 Web アクセス]

ちなみに、今あなたが使っているIPアドレスは「18.116.63.236」だったりします。

インターネット上の DNS は A/AAAA を分け隔てなく回答をするので、リゾルバを IPv6 用の DNS に向けなくても IPv6 の名前解決できます。

DMZ作成テスト

LAN 側が大方カタ付いたので、次は DMZ です。

DMZ も省力化を目指したいので、RA + DHCPv6 で行く方針にしました。自動構成されるアドレスは、静的割り当てが保障されている EUI-64 にします。
DHCPv6 はステートレス一択ですが、さて誰に喋らせるか... 一番ヒマにしている DNS が良さそうです。
IPv6 アドレスは、DMZ で、ULA を構成してもあまり意味がないので、GUA のみって事にしました。

まずは公開 DNS の構成です。IPv6 アドレスを手動で構成したワークグループの Windows Server 2008 に DNS をインストールして、正/逆引きのゾーンを作成し、コンテンツサーバのみの設定とセキュリティチューニングをして基本設定完了。

[公開DNSのIPv6設定/デフォルトゲートウェイはRAにお任せ]

ソフトバンクテレコムからは、IPv6 用のセカンダリ DNS 提供も受けているので、正引きと、IPv6逆引きのゾーン転送先に IPv6 用のセカンダリ DNS を追加しました。
今のところ AAAA 登録は、公開 DNS だけですが、こいつがゾーン転送されるかがキモですね。
しばらくして確認すると、無事ゾーン転送ができていました ^^v

DNS が正常に動作することが分かれば、次は Web サーバです。
RA と DHCPv6 が効いているので、netsh で EUI-64 にするだけで IPv6 の設定は完了です。公開サーバなので、セキュリティチューニングはお忘れなく。
準備ができた Web サーバで ipcpnfig を使って、自動構成された IPv6 アドレス調べて DNS に登録すれば公開終了。

[WebサーバのIPv6設定/全てRAにお任せ]

インターネット側からの動作確認をしようかと思った段階で... あっ.... 拙宅以外で IPv6 でアクセスできる回線が手持ちに無い(汗)

ところが、世の中には便利なサービスがあって、IPv4/IPv6 の中継をしてくれるサービスがあるんですね。
今回は、この手のサービスを提供している SixXS(http://www.sixxs.net/)のサービスを使ってみました。
使い方は簡単で、通常の URL に「.ipv4.sixxs.org/」を付加するだけです。拙宅のサイトだと「http://www.vwnet.jp.ipv4.sixxs.org/」とすれば、IPv4 only ネットワークから IPv6 Web アクセスが出来ます。

外部の IPv4 環境から IPv6 で接続できることを確認して、Web サーバ公開も成功 ^^v

話は前後しますが、ファイヤウォール設定も必要ですね。
IPv6 自動構成の場合は、NIC を変更しただけで IPv6 アドレスも変更されます。サーバの入れ替えや修理を考えると、IPv4 で良くやっているサーバ個別のルールでは運用の負担になるので、セグメントに対するポリシーを実装する事にしました。公開サービスを DMZ 単位で許可するってアプローチです。
最近の OS は、ファイヤウォール機能を持っているので、個別のセキュリティ設定は個々のサーバで実装します。

ある程度環境が整ったので、通信しているパケットをキャプチャしてみると、思った以上に ICMP を使っていますね。DMZ でイン/アウトバウンドの ICMP と ICMPv6 は双方向通過許可にするのが良さそうです。この考え方で言うと、インターネット/LAN 間の ICMP/ICMPv6 も通すのが良いと思われますが、このあたりはポリシーをどう考えるかに依存しますのでサイト管理者の考え方次第ですね。。(うちのサイトでは通すことにしました)

サブネットプレフィックスとルーティング

IPv6 の 実装目処が立ったので、実運用での IPv6 ネットワーク設計について考えてみましょう。

スタティックルーティングで何とかなる規模のネットワークであれば、サブネットプレフィックス(セグメントプレフィックス)設計は軽く流してもいいのですが、ダイナミックルーティングじゃないとやってられないような規模になると、思いつきでサブネットプレフィックスを振り出していると、あっという間に行き詰ってしまうだけではなく、ルーティングのオーバーヘッドが無視できなくなってしまいます。

サブネットプレフィックスとルーティング設計はどうするのが良いのかと色々設計手法を考えてみたのですが、このあたりは IPv4 と同じで、ピラミッド構造のネットワークにして、必要セグメント数をサブネットIDのビット数で表現できる数に丸めて積み上げるってスタンダードな結論にたどり着きました。
要は、必要数を順番に取って割り当てて行くって IPv4 と同じアプローチです。

設計サンプルは、pptx に書いているので、そっちを参照して(解読して)下さい。

セグメント数が複数ある場合は、小規模でもダイナミックルーティングが便利です。IPv6アドレスはやたらと長いので、手でスタティックルーティングを書くのは現実的ではありません。
全ての GW に RA を喋らせた場合は、遠い側の GW にパケットが行っちゃうことも想定されますが、ダイナミックルーティングが正常機能していれば何もせずとも正しい GW に転送されますし、1セグメントに対して複数の GW が RA を喋っているので、1台が機能停止しても、RA が止まらなくて済みます。

ダイナミックルーティングは、IPv6 Ready Logo 取得の機器であれば通常サポートされていますが、Logo を取っていない製品だと、RIPng すら扱えない機器もあったりしますので、その際はスタティックルーティングを書く必要がありますけどね。

ちなみに、IPv6 のスタティックルーティングは、Next Hop だけではなく、送出ポートも併記するのが原則となっているようです。

例えば、YAMAHA の RT シリーズだと「ipv6 route default gateway 2001:278:101d:f::ff:1%1」みたいに、Next Hop に続いて「%」を書いて送出ポート(この例では LAN1)を指定します。

運用環境へ移行

テストでは、話を簡単にするために YAMAHA RTX1100 のみで環境構築しましたが、拙宅の運用環境では Fortinet 社の FortiGate 60(UTM 製品/個人宅で使う代物ではないw)を使っています。
IPv4 only 時は、FortiGate に PPPoE を搭載していましたが、FortiGate に 6over4 over PPPoE の設定をしても、トンネルがうまく動かないんですよね。サポートもギブアップしちゃったぽいw

仕方が無いので、PPPoE と 6over4 は実績のある RTX1100 を使い、FortiGate では純粋な IPv6 ファイヤウォールとして動かす方針に変更。

[ネットワーク構成変更]

ネットワーク構成が大きく変わるので、切り替えは大変でしたが、何とか運用環境に持ち込むことができました。
これを書いている時点の FortiGate60 は、RA で複数プレフィックスが喋れないとか、RIPng が実装されていないとか色々問題はありましたが(そもそも FortiGate60 は IPv6 Ready Logo を取っていないし)、工夫次第で何とかなるもんです。

# RTX1100の設定
# RTX1100 Rev.8.03.70 (Mon Feb 18 20:55:48 2008)
login password *
administrator password *
console columns 200
console lines infinity
ip route default gateway pp 1
ip filter source-route on
ip filter directed-broadcast on
ipv6 route default gateway tunnel 1
ipv6 route 2001:278:101d::/48 gateway 2001:278:101d:ffff::ff:2%3
ip lan3 address 211.121.188.193/29
ipv6 lan3 address 2001:278:101d:ffff::ff:1/64
ipv6 lan3 mld router syslog=on version=1,2
pp select 1
 pp always-on on
 pppoe use lan2
 pppoe auto connect on
 pppoe auto disconnect on
 pp auth accept pap chap
 pp auth myname ID Password
 ppp lcp mru on 1454
 ppp ccp type none
 ip pp mtu 1454
 ip pp secure filter name PPPoE
 pp enable 1
tunnel select 1
 tunnel encapsulation ipip
 tunnel endpoint address 211.121.188.193 218.218.255.213
 ipv6 tunnel address 2001:278:0:221d::2/64
 ipv6 tunnel secure filter in 1000 2000 9999
 ipv6 tunnel secure filter out 1001 2001 9999
 ipv6 tunnel mld host syslog=on version=1,2
 ipv6 tunnel tcp mss limit auto
 tunnel enable 1
ip filter 1000 reject 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,211.121.188.192/29 * *
ip filter 1001 reject * 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,211.121.188.192/29 *
ip filter 2000 reject * * tcp * telnet
ip filter 2001 reject * * tcp telnet *
ip filter 9999 pass * * * * *
ip filter set PPPoE in 1000 2000 9999
ip filter set PPPoE out 1001 2001 9999
ipv6 filter 1000 reject fc00::/7,ff05::/16,2001:278:101d::/48 * * * *
ipv6 filter 1001 reject * fc00::/7,ff05::/16,2001:278:101d::/48 * * *
ipv6 filter 2000 reject * * tcp * telnet
ipv6 filter 2001 reject * * tcp telnet *
ipv6 filter 9999 pass * * * * *
ipv6 filter 10000 pass * * * * *
syslog host syslog-host
syslog notice on
dns server 143.90.130.165 143.90.130.39
schedule at 1 */* *:00 * ntpdate ntp.nict.jp syslog
httpd host none

デフォルトゲートウェイ設定を楽にする

IPv6 は RA での自動構成にしていれば、基本的にデフォルトゲートウェイの設定は不要なのですが、RA を使いたくないセグメントや、フルスタティックで IPv6 アドレスを構成する場合にはデフォルトゲートウェイアドレスの設定が必要になります。

さて、そのような場合はどうするか。GUA と ULA をルータに設定しているので、これをIPv6 のデフォルトゲートウェイに設定すればいいのですが、IPv6 アドレスは悪夢のように長いので、複数の IPv6 アドレスは書きたくありませんし、ミスの元になっちゃいますね。

RA で自動構成されたノードで IPv6 がどのように構成されているかを良く見ると.... デフォルトゲートウェイが「fe80::/10」のリンクローカルになっているのに気がつくはずです。
そう、デフォルトゲートウェイはリンクローカルアドレスを指定すれば良いのです。リンクローカルアドレスは、リンクに閉じた IPv6 アドレスなので、面白い事に L3 中継層の各リンクに対して同じリンクローカルアドレスを設定することが可能なのです。

つまり、3ポート(3セグメント)ルータでも、各ポートに「fe80::1/10」を割り当てる事が可能なのです。
デフォルトゲートウェイとなるポートに fe80::1/10 を割り当てておけば、どのセグメントであっても、手動でデフォルトゲートウェイを設定する時には fe80::1 と1つだけ入力するだけで済みます。

YAMAHA RTX1000 だとこんな感じです

ipv6 route default gateway fe80::1%3 ← LAN 3 セグメントにある上位ルータ(fe80::1)にでフォルトゲートウェイを向ける(ダイナミックルーティングなら不要)
ipv6 lan1 address fe80::1/10 ← LAN 1 に fe80::1/10 を割り当てる
ipv6 lan1 prefix fd75:f582:7ae3:10::/64 ← LAN 1 の ULA アドレス自動生成
ipv6 lan1 prefix 2001:278:101d:10::/64 ← LAN 1 の GUA アドレス自動生成
ipv6 lan2 address fe80::1/10
ipv6 lan2 prefix fd75:f582:7ae3:20::/64
ipv6 lan2 prefix 2001:278:101d:20::/64
ipv6 lan3 address fe80::2/10 ← LAN 3 で上位ルータへのルーティングをするので fe80::1/10 ではなく、fe80::2/10 を割り当てる(ダイナミックルーティングなら不要)
ipv6 lan3 prefix fd75:f582:7ae3::/64
ipv6 lan3 prefix 2001:278:101d::/64

FortiGate の IPv6 設定

このページへのアクセスを解析すると、FotiGate をキーワードにいらっしゃる方が多いので、FortiGate の IPv6 設定も書いておきますね。

英語ですけど、IPv6 のマニュアル(IPv6 Technical Note)はこちらからダウンロードできます。

僕が使っている Fortigate-60 3.00-b0730(MR7 Patch 1) でも実装が若干甘いながら IPv6 を使うことができます。ただし GUI を使った設定では、UI 実装がバグっているとか、設定項目そのものが無かったりするので、コマンドライン(telnet)での設定にします。
4.1 あたりからは GUI 設定できるんではないかなと予想しています。
(4系で IPv6 Ready Logo Phase-2 を取得したそうです)

telnet で FortiGate に接続するとログインプロンプトが来ますので、管理権限を持ったアカウントでログインします。

Fortigate-60 login:
Password: *********
No entry for terminal type "vt100";
using dumb terminal settings.
Welcome !

Fortigate-60 $

ログインしたら、コマンドラインで設定しましょう。まずは FortiGate そのものの IPv6 設定です。モードを一つ戻すときは「end」を使います。

config system interface
edit "internal" ← 設定するインターフェイス
set type physical
config ipv6
set ip6-address 2001:278:101d::ff:1/64 ← インターフェイスの IPv6 アドレス
set ip6-other-flag enable ← O フラグ ON
config ip6-prefix-list
edit 2001:278:101d::/64 ← RA で広告するプレフィックス(GUA)
set autonomous-flag enable
set onlink-flag enable
next
edit fd75:f582:7ae3::/64 ← RA で広告するプレフィックス(ULA)
set autonomous-flag enable
set onlink-flag enable
next
end
set ip6-send-adv enable ← RA ON
end

良く使うアドレスのグルーピングはこんな感じです。

config firewall addrgrp6
edit "LAN-DC-IPv6"
set member "LAN-DC01-GUA" "LAN-DC01-ULA" "LAN-DC02-GUA" "LAN-DC02-ULA"
end

ポリシーの実装は IPv4 と変わりありません

config firewall policy6
edit 1
set srcintf "internal"
set dstintf "dmz"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ANY"
set profile-status enable
set logtraffic enable
set profile "filter_wizard"
end

スタティックルーティングはこんな感じで書きます

config router static6
edit 1
set device "wan1"
set dst 2000::/3
set gateway fe80::1
next

ちなみに、ダブルコーテーションは省略しても認識されるようです。

設定がすんで FortiGate との接続を終了する時は、初期プロンプトまで end で戻って quit します。

NGN

IPv6 普及の切り札になるのかなと思っていた NGN が、「マルチプレフィックス問題」で苦戦していますね。

一部の報道(雑誌)では PC の OS 実装が甘いのが原因みたいな情報が伝えられていますが、それは間違いで、NGN そのものの問題です。

NGN はインターネットにルーティングを広告しない閉域網です。閉域網として考えられているので、網内の設計は素晴らしいのですが、ISP と接続をしてインターネットへの橋渡しをする部分の設計が甘かったと言われてもしょうがないような状況なんですよね。
「NGN=フレッツ地域網」ってノリで ISP 接続を設計していた様ですが、フレッツ地域網と決定的に違うのが、NGN の IPv6 アドレスを ISP 利用ユーザに使わせようとした所です。

今のフレッツ網でマルチプレフィックスが問題になっていないのは、ISP 利用者がインターネットアクセスとフレッツのサービスを併用して使っていないからでしょう。
僕もフレッツ網そのものの速度計測をするためにフレッツスクエアに接続した事ありますが、ISP 接続環境と併用できるような仕様のものではありませんでした(フレッツ網内専用の DNS アドレスすらわかりやすい所に公開していないし、使用アドレス空間も良くわからないのでルーティングテーブルすら書けない)。
フレッツ地域網は ISP へ接続するための「PPPoE 中継専用ネットワーク」として使われているから問題になっていないだけだと推測しています。

IPv4 インターネットアクセスは、IPv4 over PPPoE なので、ISP 接続の PPPoE だけを使っている限りフレッツ網(フレッツスクエア)には接続できません。フレッツ網に接続するためには、フレッツ網用の PPPoE に接続する必要があります。

IPv4 only の時はこれで良かったのですが、IPv6 はマルチプレフィックスが標準仕様なので、NGN 閉域網のプレフィックスも広告しようと目論んだのが諸悪の根源なのかなと。
僕は NGN を契約していないのですが、NGN は GUA を使っているって情報を頂きました。インターネット側へのルーティング広告をしていない閉域網って性格から考えると、ULA で良いと思うのですが....
NGN 内が ULA であれば、インターネットをアクセスする際は、RFC3484/5220 の規則に則って ISP が広告する GUA を送信元として選択するので、送信元 IPv6 アドレスを間違うって事は無いのですが、GUA を使っているので、送信元 IPv6 アドレス選択を間違う可能はゼロではありません。

もう一つ問題になりそうなのが、ユーザのサイト境界に設置されるゲートウェイ(HGW)でルーティングをどうするかですね。

NGN では PPPoE を使いません。NGN を使ったインターネット接続方式を大きく分けると、ユーザ/ISP 間を ipip トンネルで結ぶトンネル方式と、NGN 自体がインターネットの一部(ISP までの IPv6 中継網)として稼働するネイティブ方式の2案が想定されています。(具体案はもう少し細分化されて4案あります)

IPv4 only を想定して市販されている一般的な HGW のルーティングは、上位(PPPoE)に対して default gateway を1つだけ設定すれば良かったのですが、NGN を使う場合は、IPv6 ルーティングを2つ持って、default gateway を契約 ISP に向け、NGN 宛てのルーティングを個別設定する必要があります。ダイナミックルーティングを使えば解決しそうな気がしますけど、このあたりは NGN の方針が決まらないと、HGW 実装に影響してくるので、HGW メーカーも動きたくても動けないって状況なんでしょうね。。(各契約宅に ISP が振り出す GUA プレフィックスをどうやって伝達するかってのは別の仕様として必要ですけど、これは DHCPv6 リレーを使うのかな?)

気になるのが、 名前解決ですけど、こいつは NGN 内専用のドメインを作って、そいつをグローバルに公開すれば... うーん、やっぱり無理があるな。(NGN はインターネット上に公開している DNS に NGN 内部の AAAA を登録しているようですけど)

今 NGN が考えてる仕様だと、インターネットと相互接続をするのは難しいかもですね。

僕が考えるに、NGN はフレッツ地域網と同じ位置付けの中継網に徹して、NGN のプレフィックスをユーザ側に広告しないのが今出来る最善解決策ではないかと思っています。GUA を ULA にリナンバするってのもあるとは思いますが、今更そのコストは辛いでしょうし。

さて、今後 NGN がどんな方向に進むのか注目ですね。(NGNのマルチプレフィックス解決策へ続く)

まとめ

徒然なるままに書いたので、一応まとめておきますね

使用する IPv6 アドレス

• IPv6 only は現状非現実的なので、IPv4/IPv6デュアルスタックにする

• サイトには/48、セグメントには/64プレフィックスを使う

• NAT は使わない

• ULA は fd00::/8 の計算で求めたサイトプレフィックスを使う

• LAN には GUA + ULA を割り当てる

• DMZ には GUA のみを割り当てる

IPv6アドレスの自動構成

• IPv6 アドレスは RA で自動構成

• Vista の匿名アドレスは24時間で自動更新されるが、WS08 は静的割り当てになっている

• WS08 を EUI-64 にするには 「netsh interface ipv6 set global randomizeidentifiers=disabled」

• DHCPv6 はステートレスを使う

• DHCPv6 を使うときは RA のフラグコントロールが必要

• DMZ も RA + DHCPv6 で楽ちん

• 手動設定 IPv6 だけにしたい時は ｢netsh interface ipv6 set interface [インターフェイスID] routerdiscovery=disable｣

DNSディスカバリー

• 現状の仕様では DHCPv6 リレーが必要

• DHCPv6 リレーが難しい場合は、IPv4 で DNS ディスカバリーをして暫定回避

ルーティング

• ルーティングは、ルーティング ID の16ビットで設計

• ルーティング設計手法は IPv4 と同じ

• 小規模でもダイナミックルーティングがお勧め

• デフォルトゲートウェイに fe80::1/10 を割り当てておくと手動設定時が楽

DMZ

• ファイヤウォールポリシーはセグメント単位に設定(個別ポリシーは各ホストで実装)

特別な意味を持つIPv6アドレス

ff01:: ノードローカル

ff02: リンクローカル

ff05:: サイトローカル

後日談

FortiGate60 のファームウェアを IPv6 正式対応の 3.00-b0730(MR7 Patch 1)に上げたのですが、マニュアルには RIPng と MLD が書いていないし... UI も IPv6 周りは微妙にバグっているし.... コマンドラインで設定すれば今のビルドでも使えなくはないですけど、普通に使えるようになるのは 4.1 待ちですかね(4系はリリースされましたが、拙宅で使っている 60 は対象外に orz)
うぐ、FortiGate は リンクローカルアドレスを手動設定出来ない仕様って orz

ひかり電話ルータは要注意

IPv6 導入済みの環境にNTT東(西も?)の光電話ルータを導入する際は要注意です

拙宅では、サービス開始当初から使っていた ISDN を、テストも兼ねてひかり電話に切り替えました。
NTT 東から送られてきた NTT 東のひかり電話ルータ RT-200KI を(振る舞いを確認したかったので LAN には接続せず)設置したのですが、振る舞いを見ていたら、こいつデフォルトで RA しゃべっていて、NTT 東の GUA(2001:c90::/32)のうちの /64 を構成してくれる仕様になっています。

最初は「へぇ、B フレッツも IPv6 化頑張っているんだ」と感心していたのですが... 良く考えるとマルチプレフィックス問題がここでも起きる事に気が付きました(遅

仕方なく、LAN には接続せず、ひかり電話 CTU としてしばらく使っていたのですが、メンテナンスやフレッツサービスにアクセスするたびに CTU に LAN ケーブル接続するのも面倒なので、NTT の GUA をインターネット側に吐き出さないようにフィルタして、フレッツ網への IPv4 スタティックルーティングと、IPv6スタティックルーティング(2001:c90::/32)、DNS フレッツ網内の IPv4 DNS フォワードを書いて LAN に接続したら... こいつステートレスの DHCPv6 もしゃべっていて、参照 DNS に 2001:c90:0:5::1 / 2001:c90::3 が追加されWindows の AD の認証がエラーに orz

RT-200K の GUI では IPv6 の設定が出来ないのでどうしようもありません(一応サポートに問い合わせのメール入れましたが、どんな返事が返ってくることやら)

ひかりルータを導入すると、マルチプレフィックス問題だけではなく、IPv6 の名前解決にも影響が出るので、導入時には要注意です。IPv6 の設定変更が出来ればまだ対応も可能なのですが、GUI には IPv6 ブリッジの ON/OFF しかないのでどうしようもありません。

IPv6 ブリッジを止めると、とりあえず IPv6 系はしゃべらなくなる様なので、拙宅ではしばらくこの設定で運用してみます。

にしても、この中途半端な仕様は何とかしてほしいですね

NGN のマルチプレフィックス解決策

すったもんだとやっていた NGN のマルチプレフィックス問題が、2009年に一応の決着がつきました。

そもそも NGN のマルチプレフィックス問題は、NGN が閉域網であるにもかかわらず、グローバルな IPv6 アドレス体系である GUA を使っていることに端を発しています。

IPv6 では、IPv6 アドレスを持つノードが複数 IPv6 アドレスを持つ仕様です。このため、送信元に使用する IPv6 アドレス選択は RFC3484 Default Address Selection for Internet Protocol version 6 でルールが定められています。
このルールに従うと、閉域網が使用する fc00::/7 と、インターネット上で使用する 2000::/3 の両方を PC が持っていても、インターネットをアクセスする際に fc00::/7 が選択されることはありません。

ところが、NGN は閉域網であるにもかかわらず、GUA の 2000::/3 を使用しているんですよね。
GUA を使っているだけであればさしたる問題ではないのですが、NGN はユーザーに NGN 内部に設置しているサーバーに対してアクセスさせるように、NGN の RA をユーザー宅内にしゃべりたいと考えたのです。

すると何が起きるか....

PC には、NGN が振り出した IPv6 アドレスと、ISP が振り出した IPv6 アドレスがセットされます。NGN と ISP が振り出した IPv6 アドレスは、ともに GUA なので、インターネットをアクセスする際に、宛先によっては NGN の IPv6 アドレスが送信元に選択されます。
すると、戻り先が NGN となりますが、NGN は閉域網なので戻り先がインターネットから到達できない所になってしまい、送信した PC にパケットが戻ってくることはありません。

つまり、NGN が RA をしてくれると、インターネットアクセスが出来ないケースが出てくるって事になります。これが NGN マルチプレフィックス問題なのです。(NGN 内部アクセス時も同じことが言えます)

ちなみに、2011/04/28 現在で、NTT東西が閉域網で使用している IPv6 アドレスは以下が使用されています(「KB2551233 Internet Explorer などで NTT 東日本、NTT 西日本の IPv6 閉域網に接続している環境でタイムアウトが発生する」より引用)

この問題を解決したのが「トンネル方式」(正式サービス名は IPv6 PPPoE)と「ネイティブ方式」(正式サービス名は IPv6 IPoE)の2方式です。(2方式が併存するって不思議な結論ですね)

NGN の IPv6 インターネット接続(NTT東日本のプレスリリース資料を簡略化)

まずは、ネイティブ方式です。
NGN の RA はせずに、ISP か振り出した GUA を使って NGN をアクセスするって普通な仕様です。でもよく見ると、代表 ISP って特別な ISP だけが NGN への相互接続を許されています。ルーティングコントロールのキャパの問題って理由だそうで、代表 ISP は3社に限定されています。このため、3社以外の ISP は、代表 ISP の傘下に入るので自由競争を阻害しかねないように思えます。

もう1つのトンネル方式です。
こいつも NGN の RA はしませんが、NGN をアクセスする際には アダプタ内部で IPv6 NATで送信元を NGN の IPv6 アドレスに変換しちゃいます。
そもそも IP の思想は透過通信なのですが、IPv4 アドレス枯渇が迫って NAT するって歪んだ仕様を狗肉の策で導入したって経緯があります。この仕様も IPv6 の出現で本来の姿に戻るって思っていたのに....

そんなこんなで、NGN のマルチプレフィックス問題は一応の解決はしたのですが、どちらの案もスッキリ解決とは言えないように思えます。

IANA のグローバル IPv4 アドレス在庫がゼロに

2011/02/03 に IPv4 アドレスの中央倉庫である IANA の在庫がゼロになりました。いよいよ IPv4 アドレス枯渇が秒読み段階に入ったことになります。

最後の /8 5ブロックは配布は、ストリーミングで全世界に中継され、日本語同時通訳も1,300人が視聴していました(僕もその中の一人)。

日本が所属している APNIC は、世界人口の半分近くをカバーする巨大な RIR です。このため、APNIC が在庫として持っている IPv4 アドレスが世界で一番早くなくなり、本当の意味での IPv4 アドレス枯渇にを迎えます。2011/02/05 現在で、APNIC の在庫枯渇は 2011/09/22 と予測されています。
日本国内を見てもスマートフォンの普及やネットビジネスの拡大等で IP アドレスの消費は加速しています。

日本の IPv4 アドレスを管理している JPNIC は在庫を持っておらず、直接 APNIC から ISP に IPv4 アドレスを割り当てしています。このため、日本は世界で一番早く IPv4 アドレス枯渇を迎える国の一つなのです。

IPv4 アドレスが枯渇したからと言って、新たな IPv4 アドレスが割り当てられなくなるなるだけなので、IPv4 を使ったインターネットが使えなくなるわけではありません。
閉域網であれば IPv6 の導入は必要ありませんが、インターネット接続しているのであれば、インターネット上で使われるスタンダードなプロトコルは IPv4 から IPv6 に徐々にシフトするので、現在 IPv4 only の環境であっても IPv6 導入は避けて通れないことになります。

余談ですが、APNIC の在庫が1ブロックになった段階で、JPNIC から直接割り当てを受ける指定事業者(LIR)や企業には、/22 が1つ割り当てられるだけと言うポリシーにシフトされます。この /22 は ISP や一般ユーザーに割り当てるのでなく、IPv4 インターネットの接続性を確保するための内部機材用の位置付けのようです。
ちなみに、2011/02/05 現在で、APNIC の在庫は 3.9 ブロックとなっています。

IPv6 導入には、投資(機材購入だけではなく設計等も)必要なのですが、20-30億人が IPv6 only のインターネットアクセスになるらしく、IPv6 導入は遅かれ早かれ必須事項となりそうです。

痛みを伴う IPv6 導入ですが、IP 本来の透過でエンドツーエンドな通信が蘇るので、今では想像もできないような新しいサービスが提供される事が期待がされています。

世界レベルで見るとレガシー機器が生き残り続けるので数十年は IPv4/IPv6 併存が続きそうですが、日本ではリプレース間隔が短いのでIPv6 対応は10年を待たなくても完了できるかもですね。

APNIC のグローバル IPv4 アドレス在庫がゼロに

2011/04/15 に JPNIC がアドレス供給を受けている APNIC のグローバル IPv4 アドレスがゼロになりました。JPNIC では独自に在庫を持たないので、同日付で日本の IPv4 アドレスも枯渇したことになります。

< JPNIC IPv4アドレスの在庫枯渇に関して >
http://www.nic.ad.jp/ja/ip/ipv4pool/

< APNIC's IPv4 pool usage >
http://www.apnic.net/community/ipv4-exhaustion/graphical-information

APNIC の在庫を見ると、まだ1ブロック残っていますが、APNIC のラスト1ブロックポリシーで、ISP とかの事業者に対して /22 のアドレスを IPv4 インターネットとの疎通確保用途に1度だけ配布する事にしているので、事実上の枯渇が到来したことになります。

いよいよ IPv6 の出番ですね。

[ Back ]
[ Home ]

Copyright © MURA All rights reserved.