あるドメイン名を持つホストとの通信は、特定のIPv4/IPv6ルータを 使いたい、と思ったとき、「それはレイヤが違うので標準にない」 という状況がある。ほんとに、たいしたことではないのだが、 省庁の縦割り行政がどうの、というのと同じくらい縦割りの股裂き。

かろうじて、あるドメイン名を持つホストの名前解決については、 特定のDNSサーバに問い合わせる、という実装がDNSリゾルバと フレッツ対応ルータなどにある。

しかし、あるホスト www.example.com についてのみ、デフォルト ゲートウェイではなく、ある特定の ルータ 1.1.1.1 を使おうとするとき、経路制御とドメイン名(ゾーン名) による制御の連携がないため、簡単にできない。

そのため、ある特定の接続をMACレイヤで切断したり、遮断または 横取り・介入・インターセプトする、という野蛮なことをしなければ ならない。なぜIPv4/IPv6には経路制御があるのか？ それを 「マルチホーミング」などと特別扱いしなければならないほど 特別扱い、あるいは壁として扱っているところが、現在のIPを 利用したソフトウェアの「ガラパゴス」。

「ガラパゴスとは、何かの壁を作ってまわりを囲んでしまうこと」。

IPv6で問い合わせると？ google.comのaddtional sectionにAレコードしか ないので、IPv6でのDNS名前解決手順は中段され、IPv4で名前解決を 継続しなければならない。gtld-servers.netではGoogle over IPv6ホワイト リストは適用されていないと思われるが。

それにしてもGoogleが報告する不具合は深くてこわい。 ちゃんと原因を発見しているところがえらいのだが、 もっとライトに運用したい人にはIPv6はまだ熟成されていない、 という印象を強くする。

• SoftBank YahooBBからの発表:
  
  要件:
  • IPv4とIPv6の両方の接続性を持たなければならない
  • 近い将来、新たなIPv4グローバルアドレスを得られなくなる
  • IPv6によっても、IPv4共用によっても新たな売上げ(ARPU)は得られない ため、投資コストと運用コストを最小限にしなければならない
  • IPアドレス割当の維持が必須で、拡張性を持たなければならない

  CPEの設定変更コストも最小限に(ADSL IPv6 prefixは IPv4から生成)
  ADSLの場合、ユーザごとの平均帯域は2.3Kbpsであり、 6rdはひとつのトンネルで全加入者を収容するため、 ユーザごとのトンネル収容に比べトンネルサーバ数は約1/20で済む。
  LSN(Large Scale NAT)をがんばる(A+Pの方向)
  NTT東西との接続はPlan-2(IPv6 over PPPoE)かPlan-4( IPv6ネイティブをソースルーティング)

• AT&Tの資料はよくわからず
• Comcastは"xfinity":
  
  • http://ipv6.comcast.net/ あり
  • 2010年は4つのトライアル: IPv4環境での6rd、ネイティブデュアルスタック(個人/法人)、IPv6-only上でIPv4をDS-Lite
  • 2011年から先行サービスを開始、将来はdual-stackを実現
  • 5月以来、6to4のトラフィックが4倍になった
  • ComcastのIP接続パートナーの75%は IPv6対応済み
  • 新しい接続はすべてIPv4/IPv6デュアルになっている
  • 既存のパートナーへのIPv6追加は"フルスイング"

• Yahoo!(U.S.)の発表
  • CGN, NATはダメ: 位置情報、不正利用低減、性能に対して影響する
    IPv6はこのような問題を迂回できる
  • IPv6実装が不完全な機器を利用するユーザの問題
  • データセンタと協調してIPv6をテスト中(～2011半ば)
  • リバースプロキシでIPv6 からIPv4 に変換させている
  • DNS応答にIPv6対応サイトを特定するためのホワイトリストを適用

• FaceBookの発表
  • ロードバランサでIPv6とIPv4を変換している
  • Facebookは最初のメジャーな LISP 採用サイト
    LISP: Locator/ID Separation Protocol
  • LISPはCisco XTRを利用して4時間で導入した
  • LB版 - http://www.v6.facebook.com/
  • LISP版 - http://lisp6.facebook.com/

• LLNW - Limelight Networkの発表 - 進んでいる
  • Provision of http://ipv6.limelightnetworks.com(完了)
  • IPv6 SSL
  • Standardized v4/v6 DNS architecture
  • Google Apps over IPv6 for selected corporate LAN segments
  • AAAA RRs whitelist for all google.com services
  • Geolocation for IPv6

  • セキュリティ機器のIPv6での不具合 - "4週間でパッチが届いて直った" (軽い)

• Google の発表
  • 「不具合を見つけたら徹底的に調べよう」、「設計の中に善後策を」と慎重
  • 例: Firewallの最初の単語がマッチしても次がマッチしない
  • 例: FIBとRIBの更新処理が競合して同期しない(多くのデータセンタの サービス後数ヶ月で発生)
  • 例: インタフェース上のループでDAD(アドレス衝突検知)が動作し、 インタフェース上の設定の削除と再投入が必要になってしまう
  • 例: Linuxは受信専用インタフェースで経路のない、大きすぎる パケットを受信すると、そのパケットを無視する

• 社内の利用者は19,000人、36ヶ国の70ヶ所のオフィス。
• ホストから接続していたGREトンネルを、ルータ経由のデュアルスタック接続へ。
• その後WANとMPLS VPN上でデュアルスタック接続

• アドレス計画 - /64 を各VLANかPtP接続へ割当
• アドレス計画 - /56を各建物へ割当
• アドレス計画 - /48を各キャンパスかオフィスへ割当する
• アドレス計画 - /42を地域レジストラからGoogleに割当してもらう

• 経路制御 - HSRPv2 末端のホストから見て最初のルータの冗長化
• 経路制御 - OSPFv3 IGPとして
• 経路制御 - MP-BGP (Multi Protocol BGP) EGPとして
• 経路制御 - SLAAC

• 経路制御方針 - オフィス集約経路をプロバイダに広報する
• 経路制御方針 - トランジット事業者からのみ、デフォルト経路を受け入れる

課題 - IPv6対応機器は一部機種、一部機能のみ。通信事業者もIPv6対応は一部のみ。

Facebook が IPv6を採用、実験中などの発表資料がある。 IPv4アドレスとIPv6アドレスをロードバランサで変換し、 サーバには一切変更を加えないアプローチと、 IPネットワークのLISPを使ってロケーションとIDの役割分担をさせる方法が紹介されている。 XTRのコマンドにipv6 lisp ... がある。

しかし、発表資料内にあるアドレスがにくい。

2610:d0:face::9

IPv6アドレスの16進数表記に"face"が使われている。そうだよなぁ。 face:b00cとかface:b009(日本語のみ)もあるが、あまり長いシャレはよくない。 www.v6.facebook.comは、 2620:0:1cfe:face:b00c::3だった。

3G接続については対応しているのか、キャリアが対応していないだけか、 よくわからず。

ロッキーマウンテンIPv6サミットという、ぱっと見たかんじ のどかな名前の会議で、「IPv6のセキュリティポリシと 運用、ツールを今準備するように」、との指摘。 そのためにはAssure6という商品を買うように、とのこと。

• SITトンネルのデバイス名はhe-ipv6になる
• he.netの routed /64アドレスはeth0につける

$ cat /etc/sysconfig/network-scripts/ifcfg-he-ipv6

# Config Script for ifup-sit

### he.net tunnel broker
### http://tunnelbroker.net/

# Uses following information from /etc/sysconfig/network:
#  IPV6_DEFAULTDEV=: controls default route (optional)
#  IPV6_DEFAULTGW=<address>: controls default route (optional)

TYPE=sit
DEVICE=he-ipv6
ONBOOT=yes

IPV6INIT=yes
IPV6FORWARDING=yes
IPV6_ROUTER=yes

IPV6TUNNELIPV4=72.52.104.74
IPV6TUNNELIPV4LOCAL=222.228.173.205
IPV6ADDR=2001:470:1f04:bc2::2/64

# IPV6_MTU=: controls IPv6 MTU for this link (optional)
# IPV6ADDR_SECONDARIES="[/] ..."

このトンネル用の経路を追加する。table 200に設定する。 この設定ファイルには ip -6 route add 以降のコマンドラインを 羅列できる。

$ cat /etc/sysconfig/network-scripts/route6-he-ipv6

# See /etc/iproute2/rt_table
dev he-ipv6 table 200

he.net の routed /64アドレスはeth0に追加する。 /etc/sysconfig/network-scripts/ifcfg-eth0に 以下の1行を追加する。Fedora 12で挟まれた部分はさわらないようにする。

IPV6ADDR=2001:470:1f05:bc2::1/64

別途、/etc/rc.d/rc.localの末尾などに追加:

### Source Address Selection ###
### RFC3484 Rule 6 Lables ###
ip -6 addrlabel add prefix 2001:0470::/32 label 10
### DELETE tunnel entry ###
ip -6 addrlabel del prefix 2002::/16 label 2

### Policy Routing ###
ip -6 rule add to 2001:470::/32 table 200

以下のコマンドで確認する。

$ sudo ifdown he-ipv6
$ sudo ifup he-ipv6
$ ping6 he.net
$ ping6 a.dns.jp

• Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules
• Requirements for Address Selection Mechanisms

Policy Routingというと、ソースアドレスやTCPなどの ポート番号を条件にして、特定のルータを指定して経路制御を 行うもの、と思う。

昨日まで試した設定がどうもうまくいかなかった。やったのは、

• IPv6 over IPv4トンネルを本張る (1つはOCNv6/PPP, 1つはHE.NET/SIT)
• 自分のサイトのIPv6アドレスはeth0に割り当てる
• HE.NET: 2001:470:1f05:bc2::1/64
• OCNv6: 2001:380:e07:10:200:f4ff:fe58:44f/64
• ポリシールーティングの設定は:
  HE.NETの2001:470:1f05:bc2::/64を ソースアドレスに持つパケットはHE.NETのトンネルに向ける

しかし、ソースアドレスにHE.NETの2001:470:1f05:bc2::1が 選択されても、HE.NETではなくOCNv6のトンネルに向かってしまう。

type unicastを指定してみたり、HE.NETのrouted /64アドレスと トンネルの終端アドレスの両方で ip -6 rule を書いてみたが、 やはり同じだった。

そこで、ソースアドレスの判定をやめることにして、宛先だけを 指定してみることにした。 Linux でのソースアドレス選択にも、「IPv6でポリシー ルーティングすればよい」とあるが、ソースアドレスでの 振り分けはしていない。IPv4のソースアドレスによる振り分けなら、 ほかにたくさん紹介例があるのだが。

ということで、上のnabekenさんの例と同じように、 ソースアドレスではなく宛先アドレスでポリシー設定をした ところうまくいった。

• IPv6 over IPv4トンネルを本張る (1つはOCNv6/PPP, 1つはHE.NET/SIT)
• 自分のサイトのIPv6アドレスはeth0に割り当てる
• HE.NET: 2001:470:1f05:bc2::1/64
• OCNv6: 2001:380:e07:10:200:f4ff:fe58:44f/64
• ポリシールーティングの設定は:
  WHOISに掲載されているHE.NETの割当IPv6アドレス2001:470::/32を
  宛先ドレスに持つパケットはHE.NETのトンネルに向ける
• それ以外はOCNv6のトンネルに向ける
• どちらかのトンネルが切れたときは、別のトンネルを使う

Fedora 12の場合、iproute2パッケージのipコマンドは もともと入っている。カーネルのAdvanced Routingも onになっているようだ。

### addrlabelはソースアドレス選択時のRFC3484 Rule 6のラベル判定表。

### HE.NETあてのIPv6ネットワークアドレスをラベル10番に設定する

### HE.NET以外の宛先はだいたいラベル1になり、
### HE.NETのソースアドレスはラベル10に判定されるので、
### HE.NET以外の宛先の場合はHE.NETのソースアドレスが
### 選択されることはない。

### 2002::/16のトンネルあてprefixもlabel 1にすれば
### よく使う経路に向けることができるので、label 2は削除しておく

$ sudo ip -6 addrlabel add prefix 2001:0470::/32 label 10
$ sudo ip -6 addrlabel del prefix 2002::/16 label 2
$ ip -6 addrlabel
prefix ::1/128		label 0
prefix ::/96		label 3
prefix ::ffff:0.0.0.0/96 label 4
prefix 2001:470::/32	label 10	### HE.NETのアドレスはここにマッチ
prefix 2001::/32	label 6
prefix 2001:10::/28	label 7
prefix fc00::/7		label 5
prefix ::/0		label 1		### HE.NET以外はだいたいここにマッチ

	### ソースと宛先がどちらもラベル1にマッチすれば、
	### そのソースアドレスが利用される

### HE.NETあてのパケットは、HE.NET用経路テーブルで処理する
$ sudo ip -6 rule add to 2001:470::/32 table 200
$ ip -6 rule
0:      from all lookup local
16383:  from all to 2001:470::/32 lookup ipv6_he_net
32766:  from all lookup main

### HE.NET用経路テーブルは、すべてHE.NETトンネルに送り出す
$ sudo ip -6 route add default dev he-ipv6 table 200
$ ip -6 route list table 200
default dev he-ipv6  metric 1024  mtu 1480 advmss 1420 hoplimit 0

### その他のパケットはすべてOCNv6のトンネルを使う
$ ip -6 route list table main | grep default
default dev he-ipv6  metric 1024  mtu 1480 advmss 1420 hoplimit 0

### 以前はHE.NETのソースアドレスが選択されていたが、
### OCNv6のソースアドレスが選択された [OK]
$ ip route get 2001:dc4::1
2001:dc4::1 from :: via 2001:dc4::1 dev ppp0  \
	src 2001:380:e07:10:200:f4ff:fe58:44f  metric 0
    cache  mtu 1390 advmss 1330 hoplimit 0

### HE.NETあてはHE.NETのソースアドレスと
### HE.NETのトンネルI/Fが選択された [OK]
$ ip route get 2001:470::1
2001:470::1 from :: via 2001:470::1 dev he-ipv6  \
	src 2001:470:1f04:bc2::2  metric 0
    cache  mtu 1480 advmss 1420 hoplimit 0

### もともとOCNv6のソースアドレスが選択されていた宛先。
### OCNv6のソースアドレスとトンネルI/Fが選択された [OK]
$ ip route get 2001:200::1
2001:200::1 from :: via 2001:200::1 dev ppp0  \
	src 2001:380:e07:10:200:f4ff:fe58:44f  metric 0
    cache  mtu 1390 advmss 1330 hoplimit 0

LinuxでIPv6トンネルを2本、OCNv6とHE.NET tunnelbrokerの両方を コマンドラインから使おうとして失敗。

ipv6.google.comやa.dns.jpからはping6が返り問題がない。 しかしa.root-servers.netにping6を打つと source address selectionが動いていて、HE.NETのソースアドレスが選択される。 しかし送出されるインターフェースにOCNv6のトンネルが選択されてしまい、 ping6の応答がない。

ip route コマンドの scope linkオプションはわかりやすそうな気がするが、 ip -6 route | grep ^feとしてIPv6リンクローカルアドレスを見ると、 IPv6にはscopeオプションはない。 しかし、ip -6 route show の表示が読みにくい。2008年当時の情報だからだろうか。

iproute2, ipコマンドの注意:

• /etc/iproute2/に、ルール、経路テーブルの設定ファイルがある。
• ip ruleはIPv4とIPv6でルールが別だがルール名が同じなので間違いやすい
• ip tunnelはPPPトンネルについては表示しない (SIT, GRE, IP-in-IPのみ)

現状確認

• ip -6 rule # 経路テーブル名の一覧
• ip -6 route list table main # テーブル main の経路
• ip -6 route list table local # テーブル local の経路

  経路を追加

• /etc/iproute2/rt_tables に "200 ipv6_ocn", "201 ipv6_he_net"を追加

$ sudo ip -6 rule add from 2001:470:1f05:bc2::/64 table ipv6_he_net
$ ip -6 rule		# IPv6の経路テーブルが追加された
0:      from all lookup local
16383:  from 2001:470:1f05:bc2::/64 lookup ipv6_he_net
32766:  from all lookup main

$ ip rule		# IPv4の経路テーブルは追加されていない
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

$ sudo ip -6 route add unicast default dev he-ipv6 table ipv6_he_net
$ sudo ip -6 route flush cache

$ ip -6 rule
0:      from all lookup local
200:    from 2001:470:1f05:bc2::/64 lookup ipv6_he_net
32766:  from all lookup main

$ ip -6 route list table ipv6_he_net
default via 2001:470:1f04:bc2::1 \
    dev he-ipv6  metric 1024  mtu 1480 advmss 1420 hoplimit 0

... しかし ...

$ ip route get 2001:503:ba3e::2:30
2001:503:ba3e::2:30 from :: via 2001:503:ba3e::2:30 \
    dev ppp0  src 2001:470:1f05:bc2::1  metric 0
    cache  mtu 1390 advmss 1330 hoplimit 0

# HE.NETのトンネルI/FではなくOCNv6のppp0 I/Fが選択された。うー

$ ip -6 route get from 2001:470:1f05:bc2::1 2001:503:ba3e::2:30
2001:503:ba3e::2:30 from 2001:470:1f05:bc2::1 via 2001:503:ba3e::2:30 \
	dev he-ipv6  src 2001:470:1f05:bc2::1  metric 0
    cache  mtu 1480 advmss 1420 hoplimit 0

... from を指定すると、期待どおりのvia と dev が表示された ...

### HE.NETのトンネルI/Fではなくeth0にrouted /64のアドレスをつけてみた
### しかし、やはりHE.NETのソースアドレスをつけながらも、出力デバイスが違う

$ ip route get 2404:6800:8007::63
2404:6800:8007::63 from :: via 2404:6800:8007::63 \
    dev ppp0  src 2001:470:1f05:bc2::1  metric 0
    cache  mtu 1390 advmss 1330 hoplimit 0

... こうしても、OCNv6から出て行って、HE.NETトンネルから返ってくる ...

$ ping6 -I 2001:470:1f05:bc2::1 2404:6800:8007::63

... ping6 コマンドで -I でHET.NETのrouted /64のアドレスを指定すれば、
HE.NETのトンネルから出て行き、HE.NETのトンネルから戻ってくる ...

... あ゛ー ...

... よく見たら、どこにping6を打っても、HE.NETのソースアドレスをつけて
OCNv6のトンネルに出て行き、HE.NETのトンネルから戻ってきていた ...

... 一部、2001:240::53、2001:200:c000::35は OCNv6経由だった ...

... ソースアドレスセレクションはOKだが、出力I/Fの選択がおかしい ...
... ポリシールーティングを設定したから？ ...

$ sudo ip -6 rule del from 2001:470:1f05:bc2::/64 table ipv6_he_net

... やはりHE.NETのソースアドレスでOCnv6に出て行く ...

$ sudo ip -6 rule add from 2001:470:1f05:bc2::/64 table ipv6_he_net
$ sudo ip -6 route add ::/0 via 2001:470:1f04:bc2::1 \
  dev he-ipv6 mtu 1300 table ipv6_he_net

... やはり同じ ...

しかし、ping6 -I he_net_ipv6_tunnel_server_addr 2001:503:ba3e::2:30 としたあと、ping6 2001:503:ba3e::2:30 が通るようになってしまった。 tcpdumpしてみると、行きはOCNv6のppp0から出て行き、帰りはHE.NETの SIT tunnel I/Fから応答が届いた。いやはや。

参考資料:

• Linuxでのルーティングとアドレス選択のフロー、ルール (2008年8月)。
• Linux でのソースアドレス選択 (2008年8月11日更新)
• iproute2メモ(2006年2月8日更新)
• iproute2+tcを使って1台で複数インターネット接続 (2000年ごろ?) - なんとなくわかりやすい解説
• 複数のプロバイダ利用について（Linux,FreeBSD）
  /etc/iproute2/を使っていて、init 用のスクリプトがあり使いやすそう。 サーバ用設定がないかもしれない。
• 簡単なソースポリシールーティング - 日本語訳-JF 2004年2月15日
  /etc/iproute2/への設定方法もあり使いやすい
• Policy Routing - Multiple Route Tables Example (2004年12月)
  iproute2の本家の複数経路表の例
• 複数の上位接続/プロバイダとの経路制御(IPv4) (2004年3月)
  次の記事と同じ内容。英語。図あり。 (日本語訳-JF 2004年2月15日)
• IPv4で2つのISPに接続する経路設定例 (2005年1月21日更新)
  DNSなど特定経路をstaticに追加、デフォルトを個別に追加、負荷分散用デフォルトを追加、 外からのリクエストへの応答に同じアドレスで応答する設定を追加、など。 古い設定の削除にsedを駆使していてたいへんそうな感じ。