デュアルスタック環境とCDN

前回、DNSサーバを利用した名前解決と利用するIPバージョンの組み合わせに関して紹介しました。今回は、IPv4とIPv6を別々のISPで接続しているような場合、DNSを利用するCDNとの相性が問題になる可能性について紹介します。

問題が発生するのは、以下の図のようにIPv4とIPv6で別々のISPを利用しつつ、キャッシュDNSサーバはどちらか片方のISPを利用しているような環境です。たとえば、フレッツでIPv4とIPv6を別々のISPにするような設定をしていたり、IPv4しか提供されていない環境で、Hurricane Electricなどが提供しているようなIPv6 over IPv4トンネルを使っているようなときに発生する可能性があります。

この図では、家庭に対してIPv4はISP Aによって提供され、IPv6はISP Bによって提供されます。ユーザが利用しているPCに設定されているキャッシュDNSサーバは、IPv4を利用しているISP Aのものを利用しています。

このような環境で、CDNによって負荷分散が行われているコンテンツをユーザが取得するときの流れをみます。

まず、最初にユーザがISP AにあるキャッシュDNSサーバを利用して名前解決を行います(1)。このとき、ユーザはIPv4とIPv6の接続性を両方持っているので、AAAAレコードの問い合わせを先に行っているものとします。また、AAAAレコードの問い合わせに使われるキャッシュDNSサーバまでのトランスポートはIPv4とします。

ISP AにあるキャッシュDNSサーバは、権威DNSサーバにAAAAレコードの問い合わせ行い、回答を得ます。ISP AとISP Bは、双方ともにIPv4とIPv6両方で運用されており、IPv6で運用されたCDNキャッシュが両方のISP内にあるものとします。

このような環境下では、権威DNSサーバは問い合わせを行ったキャッシュDNSサーバの最寄りコンテンツキャッシュであるCDNキャッシュAを、キャッシュDNSサーバへと返答します(2)。

キャッシュDNSサーバからの名前解決結果を受け取ったユーザは、CDNキャッシュAからコンテンツを取得します。このとき、コンテンツ取得に利用されるトランスポートはIPv6となるため、ユーザはISP Bを経由してCDNキャッシュAにあるコンテンツを取得します。

しかし、ISP BにもCDNキャッシュBというコンテンツキャッシュがある場合、ユーザは遠回りをしてコンテンツを取得していることになってしまいます。このような遠回りが発生するのは、CDNによる負荷分散機能の一部である権威DNSサーバが「ユーザはISP Aにいる」と認識しているために発生しています。

ISP BのキャッシュDNSサーバを利用すれば、ユーザはCDNキャッシュBからIPv6トランスポートを利用してコンテンツを取得できるようになりますが、今度は逆にIPv4でのCDNキャッシュコンテンツ取得が遠回りになってしまいます。

DNSのリソースレコードごとに、利用するキャッシュDNSサーバを設定できれば、このような問題は軽減できると推測されます。たとえば、IPv4のAレコードを取得するときと、IPv6のAAAAレコードを取得するときに利用するキャッシュDNSサーバをそれぞれ設定することによって、キャッシュDNSサーバとのトランスポートとリソースレコードをマッチさせることができれば回避可能です。しかし、現時点では、そういった使い分けが行われることは稀であるため、このような問題が発生していると思われます。

ただし、このような状況に陥ったとしても、単に遅くなるだけでユーザが気がついていない可能性も考えられます。そもそも、CDNとの相性を追求するような設定をユーザ側が行うことが正しいのかどうかという問題もあります。

この話は多少マニアックではありますが、IPv4とIPv6のデュアルスタック環境において発生する課題発見や運用ノウハウの蓄積は、まだまだこれからかも知れません。

IPv6とIPv4とDNSの話

インターネットは、IPパケットを利用した通信です。IPパケットの宛先や、そのIPパケットの送信元はIPアドレスという固定長の識別子によって示されています。しかし、IPアドレスだけだと人間がわかりにくいので、www.example.comのような「名前」が利用されます。

名前のままでは通信ができないので、名前に対応するIPアドレスを調べる「名前解決」が行なわれます。この名前解決を行うためにDNSが使われる場合、ユーザはDNSサーバに対してIPv4アドレスやIPv6アドレスを問い合わせます。

DNSへの問い合わせは1回に1つだけ

DNSプロトコルの基本は、1987年に発行されたRFC 1034RFC 1035が基本となり、その後各種変更が別途RFCとして発行されています。

RFC 1034には、基本的なDNSの仕組みとして、UDPデータグラムかTCPコネクションを通じた問い合わせに対して、回答するか、エラーを通知するか、他のネームサーバを参照するといった返答が行なわれるとあります。

このときやりとりされるDNSメッセージは、RFC 1035に以下のように記載されています。DNSメッセージは、Header、Question、Answer、Authority、Additionalの5つのセクションに分かれています。

DNS message format

Questionセクションは、問い合わせの内容を記述するために使われます。Questionセクションに含まれる”question”は、以下のようになっています。

Question Section

この”question”は問い合わせを行う文字列が含まれます。RFC 1035に記載されている仕様上は同時に複数の”question”をQuestionセクションに含むことが可能と読めますが、現在は事実上単一のレコードに対してしか問い合わせは行えません。

そのため、IPv4とIPv6の両方のIPアドレスをDNSサーバに問い合わせる場合には、DNSサーバに対する問い合わせは、Aレコード(IPv4アドレス)の問い合わせと、AAAAレコード(IPv6アドレス)の問い合わせが別々にそれぞれ1回ずつ、合計2回発生します。

DNSサーバへの問い合わせとトランスポート

さて、さらに話がややこしくなるのですが、DNSサーバに対する問い合わせのトランスポートと、問い合わせの内容は全く独立です。

たとえば、上記図のようにDNSサーバへのトランスポートはIPv4 UDPで行い、IPv6を示すAAAAレコードを問い合わせることが可能です。逆に、IPv6 UDPをトランスポートとして利用し、IPv4を示すAレコードを問い合わせることも可能です。

組み合わせとしては、以下の4パターンが可能です。

  • IPv4トランスポート、Aレコードを問い合わせ
  • IPv4トランスポート、AAAAレコードを問い合わせ
  • IPv6トランスポート、Aレコードを問い合わせ
  • IPv6トランスポート、AAAAレコードを問い合わせ

このように、IPv4でもIPv6の名前解決が行えるようにすることで、IPv6が整備されていない環境においても、IPv6に関連する名前解決が可能とするためという意味合いもあります。もし、IPv6でのみAAAAの検索可能という仕様であれば、特定の名前解決を行う際に関係する全てのDNSサーバがIPv6対応している必要が生じます。

13系統あるDNSルートサーバのうちの6系統にIPv6アドレスが設定され、IPv6トランスポートによるDNSルートサーバへの問い合わせが可能になったのが2008年2月4日です。もし、IPv6トランスポートでしかAAAAレコードの問い合わせができない仕様であったのであれば、2008年2月以前はAAAAの名前解決が全て不可能であったと予想できます。

RFC 3901(DNS IPv6 Transport Operational Guidelines)には、すべてのDNSゾーンはIPv4のみか、IPv4とIPv6のデュアルスタックで運用されるべきであると書かれています。IPv6のみでDNSゾーンを運用すべきではないとあるのです。

このように、IPv4とIPv6は直接的な互換性がない別々のプロトコルでありながら、名前空間は共有しているのです。

次回はCDNとの相性の話です

次回は、DNSサーバに対するトランスポートとしてIPv4とIPv6のどちらを使うのかと、CDNとの相性に関して紹介します。

ShowNet 2016でのBGP Flowspec活用法まとめ [Interop Tokyo 2016]

こんにちは。あきみちです。Interop Tokyo 2016取材記事第二弾です。

特定のフローに対する設定情報をBGP(Border Gateway Protocol)のNLRI(Network Layer Reachability Information)で広告できるBGP FlowspecがShowNet 2016で活用されています。

BGP FlowspecのRFCは、RFC 5575として2009年に発行されていますが、その中では、ACL(Access Control List)やファイアウォール設定を行うために使うという用途が紹介されています。

BGP Flowspecの標準化は2009年に行われていましたが、ネットワーク機器への実装が増えてきたのは、ここ2年ぐらいです。ネットワーク機器への実装が増えてきた背景のひとつとして、大規模なDDoSトラフィックへの対処への要求が増え、それを行う要素技術のひとつとしてBGP Flowspecが注目されたことがあげられます。

今年のShowNetでのBGP Flowspec活用は、以下の5種類です。

  • ACLの配布
  • IPv6対応(Rate limit、Discard、Marking)
  • NFV(サービスチェーニング)へとVRFリダイレクト
  • セキュリティオーケストレータからの動的ACL設定
  • DDoS detection装置との連携

ACLの配布は、ShowNet外部からShowNet内部に対するtelnetなどのトラフィックを遮断するなどが行われています。

BGP FlowspecのIPv6対応は、いままさにIETFで標準化が行われていますが、RFC発行に先駆けて実装が登場しているので、今年のShowNetではそれらが活用されています。

今回のShowNetでは、dcwest内にNFV関連の展示をまとめたエリアが作られています。NFVを経由してからShowNet内の出展社ブースなどに転送されるべきトラフィックに関する設定がvMXで行われ、その設定をBGPルータに対して配布するためにBGP Flowspecが使われています。

flowspec-interop-2016

セキュリティオーケストレータからの動的ACL設定、DDoS detection装置との連携に関する話は、別途記事を書きます。

今回のShowNetでは、昨年と比べてBGP Flowspecの活用方法が増えていますが、これら意外にも様々な活用手法のひろがりがありそうです。もはやBorder Gatewayではなくなりつつあるぐらい、様々なものがBGPへと突っ込まれているような気がしている今日この頃です。

サーバ管理者向け、IPv6対応セミナー in 恵比寿 開催のご案内

みなさま、IPv6への接続はできてますか?

ユーザ環境は気付かないうちにIPv6化されていたりするのですが、サービス提供側でのIPv6対応はあまり進んでいません。
その現状を踏まえ、JPNIC様と共同で「サーバ管理者向け、IPv6対応対応セミナー」を開催させていただくことになりました。

↓↓開催案内文


サーバ管理者向け、IPv6対応セミナー in 恵比寿 開催のご案内

北米地域のレジストリであるARINにおけるIPv4アドレス在庫の枯渇や、またApple社でのiOS 9におけるIPv6対応必須化が報道され、IPv6についてのトピックスが増えてきています。
国内での、IPv6接続が容易にできる環境も整いつつあり、知らないうちに利用する環境がIPv6に対応していたということも身近になってきました。
こうした状況の中、コンテンツのIPv6化がなされていないと、ユーザーのところに思うように届けたい情報が届いていないことも起こってくるかもしれません。

そこで、DMM.com ラボとJPNICでは、誰もが気軽に参加できる「サーバ管理者向け、IPv6対応セミナー in 恵比寿」を企画しました。

IPv6の最新動向とともに、サーバのIPv6化に向けた基礎知識を解説します。
また話者は、JPNICにおける「IPv6教育専門家チーム」のメンバーが務めますが、そのメンバーを囲んで、ビアバッシュも開催し、IPv6についてフランクな意見交換会も実施する予定です。

ぜひ多くの方にご参加いただければ幸いです。皆さまのご参加をお待ちしております。

◇日 時:2016年2月16日(火) 16:30~20:00 (開場 16:00)
※19:00頃からはビアバッシュ形式の懇親会です(参加費無料)

◇会 場:株式会社 DMM.com ラボ 本社 会議室
(東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー21F)
http://labo.dmm.com/about/access/

◇主 催:株式会社 DMM.com ラボ
<http://labo.dmm.com/>
一般社団法人 日本ネットワークインフォメーションセンター(JPNIC)
<https://www.nic.ad.jp/>

◇プログラム(予定)

16:30-17:15(45分) IPv6を取り巻く最新動向
話者:株式会社インテック 廣海緑里

17:15-18:45(90分) サーバのIPv6化入門
話者:株式会社ブロードバンドタワー 許先明、國武功一

18:45-19:00(15分) DMMのIPv6に関する取り組み
話者:株式会社 DMM.com ラボ 佐々木健

19:00-20:00(60分) ビアバッシュ懇親会 ~IPv6の小話をしよう~

◇対象者:IPv6に興味のある方・対応を考えたいサーバ管理者など

◇参加費:無料

◇当日の持ち物:名刺2枚と筆記用具

◇定員:70名

◇U R L:https://www.nic.ad.jp/ja/topics/2016/20160126-01.html

◇参加申し込み:tech-seminar[at]nic.ad.jp 宛に以下の情報を、2月15日18時ま
でにお送りください。ただし定員になり次第、締め切ります。

Subjectは、「2月16日 IPv6セミナー申し込み」としてください。

– お名前:
– ご所属先:
– 業種と職種:
– メールアドレス:

◇その他: 当日、会場ではWiFiをご利用いただけます

◇お問い合わせ先:IPv6対応セミナー 事務局 <JPNIC内>
Mail: tech-seminar[at]nic.ad.jp
Tel: 03-5297-2311(月~金、10:00-18:00)

自宅のLinuxルータをIPv6対応しました

メリークリスマスです。ライトノベル好きのツチノコです。路地裏バトルプリンセスは読んでいるものとして以下の話をすすめます。

前回の記事でIPv4 Linuxルータを作成するところまで紹介しました。これで6000万回線くらいにLinuxルータを普及できたように思います。

今回の記事ではIPv6対応の部分について進めていきます。内容はこんな感じです。
・Router Advertisementふりかえり
・デザインをどうするか考える
・パッケージのインストールと設定
設定の部分は前回の記事と同じく設定ファイルを貼り付けてあるので以下長いです。

Router Advertisementふりかえり

以降の説明で必要になるので、デザインの前にRouter Advertisementを雑にふりかえります。
router-advertisement

図1 Router Advertisement

上の図1のように、ルータはRouter Advertisementを用いて、各クライアント(PC1, PC2)にIPv6 prefixを配ります。今回作るルータでも当然Router Advertisementを配りたいです。

また、Flets回線においてもRouter Advertisementを用いて各家庭にIPv6 prefixを配布しています。

デザイン

IPv6対応ルータの方式は色々考えることができます。思いついたのは以下の3つでした。
構成A: IPv6パススルーを行う
構成B: IPルーティングを行う
構成C: NAPTを行う

構成A: IPv6パススルーを行う

多くのルータには、IPv4とICMPに対してはrouter(L3)として動作し、IPv6とICMPv6に対してはbridge(L2)として動作する、いわゆるIPv6パススルーが実装されています。
IPv6パススルー

図2 IPv6パススルー

上の図2では、ISPのルータ(Router@ISP)からのRouter Advertisement(RA)が、家庭のルータ(Router@home)を通って、各クライアント(PC1, PC2)に届いています。

Linuxではebtablesを利用すると同様の動作が実現できます。しかし今回は以下の理由により見送ることとしました。
・Router Advertisementを自分で出したいという気持ち!(そういうお勉強のためにLinuxルータを使っている)
・IPv4とIPv6でL2セグメントの範囲が異なってしまうこと
・L2セグメントを大きくしてしまうこと(c.f. VLANで大きいL2 networkを組むことに問題があったのでNVO3技術が出てきた)
・単に他とは違うことがしたいという気持ち

ちなみに、bridgeするのではなく、Neighbor Discovery Proxyを使うという手もあります。Neighbor Discovery ProxyはRFC4389で定義されています。しかしこれもRouter Advertisementを自分で出せるわけではないので一緒です。

構成B: IPルーティングを行う

IPv6でもIPv4と同様にIPルーティングできます。
ip-routing

図3 IPルーティングする

上の図3では、家庭のルータ(Router@home)がRouter Advertisementを受け取り、同じprefix(w:x:y:z::/64)をRouter Advertisementで各クライアントに配布しています(radvdはRouter Advertisementを出すためのLinuxのデーモンです)。あとはeth0とeth1の間で適当にルーティングしてやればうまくいくはずです。

しかし、意外な盲点がありました。radvdの設定ファイルにはRouter Advertisementで配るべきprefixを書かないといけません。しかし、ISPから振られるIPv6 prefixは完全に固定ではないということです(参考: フレッツ・v6オプション について(NTT東日本の場合))。
Prefixが変わる機会はそうそうなさそうですが、とりあえず今回は見送ることにします。

構成C: NAPTを行う

IPv6に対しても、IPv4と同様にNAPT(or NAT or IP masquerade)することができます。
napt

図4 NAPTする

ネットワークをフラグメント化させるので、オープンでセキュアなIPv6対応とは言い難いです。
しかし、上の2つの方式の課題は解決できます。
・自分でRouter Advertisementを出せる
・eth1のアドレスを固定にできる

何か負けた気もしますが、今回はこの実装を使います。
ごちうさのじゃんけんと同じく負けるべき時もあります。

その他考慮すべきことにDHCPv6があります。
WAN側については必須ではないもののDHCPv6 client動作することにします。
LAN側についてはIPv4と同じくDHCPv6 server動作することにします。

パッケージのインストール

今回のルータでは以下のような動作をすることになりました。
・WAN側: Router Advertisementを受信する、DHCPv6 client動作する
・LAN側: Router Advertisementを出す、DHCPv6 server動作する
・WAN側とLAN側の間はNAPTする。

パッケージをインストールします。

# apt-get install wide-dhcpv6-client radvd git-core

・wide-dhcpv6-client: WAN側でDHCPv6 client動作するためのデーモン
・radvd: LAN側でRouter Advertisementを出すためのデーモン
・git-core: DebianだとLAN側でDHCPv6 server動作するためのデーモンがパッケージ化されてないので、git経由で入れる
ちなみにWAN側でRouter Advertisementを受け取るためには特にパッケージは不要です。

設定

それでは頑張って設定していきましょう。
なお、日本語でコメント入れてあるところについて、環境によってエラーになるようなら取ってください。

kernel parameterの設定(/etc/sysctl.conf)

# /etc/sysctl.conf
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# ipv6 forwardingは有効にする
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

# Router Advertisementはデフォルトでは受信しない
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

# redirectは受け取らない
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# eth0(WAN)ではRouter Advertisementを受信する
net.ipv6.conf.eth0.accept_ra = 2

ご参考: accept_ra は以下のような設定値を取ります。
0: そのインターフェースでRouter Advertisementを受信しない。
1: そのインターフェースでforwardingが無効なら、Router Advertisementを受信する。
2: そのインターフェースでforwardingが有効でも、Router Advertisementを受信する。

ご参考: 2.2.10. ソースルーティングの無効化

インターフェースの設定(/etc/network/interfaces)

# /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# wan interface
auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 0.0.0.0
    up ifup ppp0
    down ifdown ppp0

iface ppp0 inet ppp
    provider dsl-provider-test

# lan interface
auto eth1
allow-hotplug eth1
iface eth1 inet static
    address 192.168.1.254
    netmask 255.255.255.0
iface eth1 inet6 static
    address fd00:01fe:0:0:0:0:0:1
    netmask 64

WAN側はRouter AdvertisementでIPv6アドレスを設定されるのでここに記述することはありません。
LAN側(eth1)にはIPv6アドレスを設定します。設定するアドレスはユニークローカルIPv6ユニキャストアドレス(ULA)を利用します(参考: インターネット10分講座:IPv6アドレス~技術解説~)。今回の例ではfd00:1fe::1/64としています。ご利用の際はランダムに生成してください(参考: Unique Local IPv6 Generator)。

DHCPv6 clientの設定(/etc/wide-dhcpv6/dhcp6c.conf)

# /etc/wide-dhcpv6/dhcp6c.conf

interface eth0 {
  information-only;

  send rapid-commit;
  send ia-pd 0;
  request domain-name-servers;
  request domain-name;
};

id-assoc pd 0 {
  prefix-interface eth0 {
    sla-id 0;
    sla-len 0;
  };
};

eth0からPrefix Delegation(参考: 書いて覚えるDHCPv6-PD)を要求します。不要な気もしていますが、eth0が受信しているRouter AdvertisementにOther Flagが立っているので念のため。

Router Advertisement Daemonの設定(/etc/radvd.conf)

# /etc/radvd.conf

interface eth1 {
  AdvSendAdvert on;
  AdvManagedFlag off;
  AdvOtherConfigFlag on;
  AdvLinkMTU 1394;

  prefix fd00:01fe::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
  };

};

eth1からRouter Advertisementを送信します。配布するprefixはfd00:01fe::/64です。

DHCPv6 serverの設定(/etc/dhcp/dhcpd6.conf)

Debianのisc-dhcp-serverパッケージはDHCP serverをインストールしてくれるものの、IPv4用のサービス登録や設定のみなので、IPv6用のサービス登録や設定を行う必要があります。設定ファイルと簡単なスクリプトを作成してありますのでそれを使います。

# git clone http://github.com/wataken44/debian-isc-dhcp-server-v6.git
# cd debian-isc-dhcp-server-v6
# sh scripts/install.sh

これでisc-dhcp-server6というサービスが登録されます。あとは設定を入れるだけです。

# /etc/dhcp/dhcpd6.conf

# ddns-update-style should be none for DHCPv2
ddns-update-style none;

shared-network LAN6 {
  subnet6 fd00:01fe::/64 {
    range6 fd00:01fe:0:0:0:1:0:2 fd00:01fe:0:0:0:1:0:1000;
    authoritative;
    default-lease-time 28800;
    max-lease-time 57600;
    option dhcp6.name-servers fd00:1fe::1;
  }
}

DNS resolverの設定(/etc/unbound/unbound.conf)

# /etc/unbound/unbound.conf
# See the unbound.conf(5) man page.
include: "/etc/unbound/unbound.conf.d/*.conf"

server:
  interface: 192.168.1.254
  interface: fd00:1fe::1
  access-control: 192.168.1.0/24 allow
  access-control: fd00:1fe::1/64 allow
  unwanted-reply-threshold: 10000000

LAN側(fd00:1fe::/64)からの問い合わせに応答します。

FirewallとIP masqueradeの設定(ip6tables)

#!/bin/sh
# ip6tables.sh

WAN_IF=eth0
LAN_IF=eth1
LAN_SUBNET=fd00:1fe::/64

# いったんルールをflush
ip6tables -t filter -F
ip6tables -t mangle -F
ip6tables -t nat -F
ip6tables -F

# filter tableはdefaultではINPUT, FORWARDはDROP, OUTPUTはACCEPT
ip6tables -t filter -P INPUT DROP
ip6tables -t filter -P OUTPUT ACCEPT
ip6tables -t filter -P FORWARD DROP

# loopbackはACCEPT
ip6tables -t filter -A INPUT -i lo -j ACCEPT
# LAN側はACCEPT
ip6tables -t filter -A INPUT -i $LAN_IF -j ACCEPT
# セッション確立後はACCEPT
ip6tables -t filter -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMPv6は利用しないredirectだけDROPし、他はACCEPT
ip6tables -t filter -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type redirect -j DROP
ip6tables -t filter -A INPUT -p ipv6-icmp -j ACCEPT

# LAN側からWAN側にForwardされる通信はACCEPT
ip6tables -t filter -A FORWARD -s $LAN_SUBNET -o $WAN_IF -j ACCEPT
# セッション確立後はACCEPT
ip6tables -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# ICMPv6はecho-request(ping)/echo-reply(pong)のみ許可
ip6tables -t filter -A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -j ACCEPT
ip6tables -t filter -A FORWARD -p ipv6-icmp -m icmp6 --icmpv6-type echo-reply -j ACCEPT

# mangle tableはすべてACCEPT
ip6tables -t mangle -P PREROUTING ACCEPT
ip6tables -t mangle -P INPUT ACCEPT
ip6tables -t mangle -P FORWARD ACCEPT
ip6tables -t mangle -P OUTPUT ACCEPT
ip6tables -t mangle -P POSTROUTING ACCEPT

# TCP MSSをpMTUにclampする
ip6tables -t mangle -A FORWARD -s fd00:1fe::/64 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# nat tableはすべてACCEPT
ip6tables -t nat -P PREROUTING ACCEPT
ip6tables -t nat -P INPUT ACCEPT
ip6tables -t nat -P OUTPUT ACCEPT
ip6tables -t nat -P POSTROUTING ACCEPT

# ipv6 masqueradeする
ip6tables -t nat -A POSTROUTING -s fd00:1fe::/64 -o eth0 -j MASQUERADE

IPv4と同じようにIPv6でもシェルスクリプトを作って、アクセス制限やmasqueradeの設定をします。

設定の反映

# sh ip6tables.sh; service netfilter-persistent save; reboot

問題なく設定されていたら、これでデュアルスタックなルータとして動作するはずです。

wataken44@cookie:~$ ping6 google.com -c 4
PING google.com(nrt04s12-in-x05.1e100.net) 56 data bytes
64 bytes from nrt04s12-in-x05.1e100.net: icmp_seq=1 ttl=54 time=3.05 ms
64 bytes from nrt04s12-in-x05.1e100.net: icmp_seq=2 ttl=54 time=3.10 ms

result
わーい。IPv6はいいぞ。

(12/26 追記) カメもはっきりくっきり踊っています。

おわりに

これで家庭用ルータのIPv6対応が出来ました。
世間一般の実装とは違いますが、副次的なメリットとして今回の実装は概ねIPv4と同様の動作をしています。
IPv6の勉強の一歩としてもわかりやすいのではないかと思います。
年末年始の自由工作にいかがでしょうか。

p.s. 転生従者の悪政改革録よいです。