BSD UnixにおいてIPv6 を有効にした際に発生する課題とその対策

WIDE Project /アラクサラネットワークス(株)鈴木伸介 <suz@kame.net>
All rights reserved. Copyright(c)2006 WIDE Project1

AbstractDNS
AAAA Queryに対する異常応答 アドレスファミリー未指定時のA/AAAAQuery順序 DNSサーバアドレス検出まとめAll rights reserved. Copyright(c)2006 WIDE Project2

AAAA Queryに対する異常応答

AAAA Queryにより異常な応答をするDNSサーバがあると、AAAA Queryを行ったときのタイムアウト待ちにより、通信遅延が発生 (RFC4074)
IPv6で問い合わせたとき限定の症状*BSDでの対応

Queryが無視される

A/AAAA Queryの順番を細工(抜本解ではないが…)

エラーメッセージが返ってくる (ホスト名不在=NXDOMAIN)
Lame Delegationになる

エラーメッセージが返ってくる (「ホスト名 エラーメッセージをトリガーに次の不在」以外)
アクション (アプリケーション依存)
壊れたrecordが返ってくる

壊れたrecordを廃棄

All rights reserved. Copyright(c)2006 WIDE Project3

アドレスファミリー未指定時のA/AAAA Query順序の工夫


一般的にはアプリケーション依存

普通は*BSD付属のライブラリの実装依存

OSQuery順序
NetBSD, OpenBSD, AAAA→A
FreeBSD (~5.3)
FreeBSD (5.4~)
KAME SNAP

A→AAAA非link-local IPv6アドレスの有無で順序を変えるあり: AAAA→A
なし: A→AAAA

All rights reserved. Copyright(c)2006 WIDE Project4

A/AAAA Query順序の調整だけでは回避しきれないケース


誰かがAAAA Queryする限り、「ホスト名不在」エラーには対応
不能
端末がA Query, AAAA Queryを送信
 A Queryにより、IPv4アドレスを学習し通信 (OK) AAAA Queryにより、キャッシュDNSサーバに「ホスト名不在」によるnegative cache生成 以降キャッシュDNSサーバにA Queryしても、IPv4アドレスを学習できない(NG)A Query for host1

A Query for host1

Host1=(ホスト名なし)
host1(A)=192.168.0.1

キャッシュDNS
キャッシュDNS
サーバ
サーバ

host1=(ホスト名なし)
host1(A)=192.168.0.1
host1=(ホスト名なし)

端末1

host1=(ホスト名なし)
host1(A)=192.168.0.1
AAAA Query for host1

端末2

All rights reserved. Copyright(c)2006 WIDE Project5

A/AAAA Query順序の調整だけでは回避しきれないケース (cont.)
AAAA Queryを行う限り「答えのないAAAA Queryのタイムアウト待ち」は避けられないKAME SNAPでは、A Queryの応答時間から適当なタイムアウト値を推測し、タイムアウト時間を必要最小限にしている。

いずれのケースも端末側ではどうしようもないAAAA Queryに異常応答をするDNSサーバの修正が必須
 駄目な場合は、アプリケーション毎の対応が不可避 (e.g.
mozilla)All rights reserved. Copyright(c)2006 WIDE Project6

DNSサーバアドレス検出
各配布方法への対応状況
RA配布: 未対応
 DHCPv6配布: 対応済 (WIDE-DHCPv6)
 Well-known Anycast address: 対応済 (手設定)

根本的な問題

どれが標準?


IETFでも標準化作業が頓挫…

仮に標準が決まったとして


DNSサーバのIPv4アドレス,IPv6アドレスがあるときどちらを優先すべきか?
All rights reserved. Copyright(c)2006 WIDE Project7

DNSサーバのIPv4/IPv6アドレスの優先度問題
IPv4/v6 Dual-Stack化により顕在化

DNSサーバアドレスをDHCPv4,v6両方で学習
c.f. 類似問題
DNSサーチパスをDHCPv4,v6両方で学習
 Policy Tableを複数の上流ISPから学習 Default Routerを複数の隣接ルータから学習

想定される問題Queryの回数が無駄に増える「なりすましDNSサーバ」への誘導に悪用することも可能


DNSサーバ(v4)

特にIPv4 onlyセグメント内で「なりすましDNSサーバのIPv6アドレス」が広告されても、ネットワーク管理者は見つけにくい
DNSサーバ(v6)PC

なりすましDNSサーバ兼DNSサーバ広告サーバ
All rights reserved. Copyright(c)2006 WIDE Project8

*BSDでのDNSサーバのIPv4/IPv6アドレスの優先度


通常はIPv4アドレスだけ使用
OS付属のDHCPv4 clientでDNS情報取得
 DHCPv6クライアント(WIDE-DHCPv6)も、デフォルトでは取得したDNS情報を端末に反映しない

必要な人だけ、DHCPv6 clientで取得した情報を/etc/resolv.conf へ反映するよう設定

実用上はこれで特に問題ないでしょう

All rights reserved. Copyright(c)2006 WIDE Project

9

まとめ

DNS関連の問題は以下の2つにより対処


壊れたメッセージを廃棄
A/AAAA Queryの順序を工夫している



が端末側の対応には限界がある→サーバ側の対応を切に望みます

DNSサーバアドレス検出

実用上はDHCPv4のみで十分

All rights reserved. Copyright(c)2006 WIDE Project10

Thanks!

All rights reserved. Copyright(c)2006 WIDE Project

11

まとめ

DNS関連の問題は以下の2つにより対処


壊れたメッセージを廃棄
A/AAAA Queryの順序を工夫している




DNSサーバアドレス検出

実用上はDHCPv4のみで十分

Source Address Selection

が端末側の対応には限界がある→サーバ側の対応を切に望みます

一部実装済
動的Source Address Selection Policyは、複雑な割に有効な局面が少ない感があるDefault Gateway SelectionRouter-Preferenceは実装済
More-Specific Route optionは未実装だが、受信のみRIPngで十分
All rights reserved. Copyright(c)2006 WIDE Project12

SWG指摘の他のネタに対するコメント

All rights reserved. Copyright(c)2006 WIDE Project13

Source Address Selection

RFC3484実装状況
longest-match rule = 全ての*BSDで実装済
 Policy Table = 一部の*BSDで実装済

FreeBSD: 5.2~
 NetBSD: まだ (KAME-SNAPでは実装済)
 OpenBSD: まだ (KAME-SNAPでは実装済)
 ただしいずれも手動設定 (ip6addrctl)で、DHCPv6などと連動した自動設定は未サポートAll rights reserved. Copyright(c)2006 WIDE Project14

Source Address Selection(cont.)


Policy Table自動設定が未サポートな背景

標準化がまだ

汎用的なPolicy Table自動設定は非常に難しい
IPv6マルチホーム問題そのもの
 一部の場合(e.g. 閉域網とInternetの同時使用)には簡単かつ効果的

上の効果的なパターンは「Unique Local Address(RFC4193) とlongest-match ruleの併用」でも対応可
Policy Table自動設定ならば/48よりも広いアドレス空間でも有効 そのメリットも、FC00::/8 (centrally-managed Unique LocalAddress) のRegistry割当が始まればなくなる可能性大All rights reserved. Copyright(c)2006 WIDE Project15

Default Gateway SelectionRouter Preference
ルータ側 = 全*BSD対応済
 端末側 = 一部BSD端末で使用可能


FreeBSD: 6.1〜
 NetBSD: -current (Jan 2006)
 OpenBSD: (KAME-SNAPのみ)

More-Specific Route
ルータ側 = 全*BSD対応済
 端末側 = 未実装
All rights reserved. Copyright(c)2006 WIDE Project16

Default Gateway Selection(cont.)

なぜ端末側でMore Specific Routeが未実装か?


kernel内実装が困難


経路制御プロトコルをkernel内で実装するのとほぼ等価

端末で「受信のみRIPng」を動かすほうが、素直かつきめ細かい制御ができるのでは?
素直=これなら、*BSD全て対応済み
 きめ細かい制御=経路制御計算を踏まえた経路広告
All rights reserved. Copyright(c)2006 WIDE Project17

到達性が無いIPv6アドレス取得


基本的にはアプリケーション依存

OSはアプリケーションにエラーを返す

host unreachable, net unreachable, ...

あとはアプリケーションがそのエラー値を見て賢く振舞うか次第

アプリケーションではエラー処理はちゃんと実装しましょう

IPv4でも同じことは起こるAll rights reserved. Copyright(c)2006 WIDE Project18

自動トンネル
*BSDではユーザが意図的に有効にしない限り、設定されない
6to4
 ISATAP (KAME) TSP (freenet6)
 L2TP (l2tpd)


そのため、指摘されたような問題は発生しない
All rights reserved. Copyright(c)2006 WIDE Project19

マルチキャストとPersonal Firewall


現状




「マルチキャストだったらデフォルト廃棄」というPersonal Firewall実装もあるが、これは非常に迷惑

提案

こんなStateful inspectionが欲しい
MLD joinしたら、そのグループ宛のパケットだけ通す その他のグループ宛のは廃棄All rights reserved. Copyright(c)2006 WIDE Project20

IPsecとmulticast
事前共有鍵による鍵交換は動く 動的鍵生成による鍵交換は未対応


IPv4/v6にかかわらない問題

All rights reserved. Copyright(c)2006 WIDE Project21