ip6.int 廃止に向けて

執筆：WIDE v6fix WG
編集：山本和彦
作成：2005年12月14日
更新：2006年3月16日

要約

2006年6月1日に ip6.int が廃止される。

これにより、逆引きにかかる時間は短くなる、すなわち改善されると予想される。

ip6.int のみを引くリゾルバは、逆引きでホスト名を得られなくなる。逆引きの機能を利用するのは主にサーバである。サーバが、ip6.int のみを引くリゾルバを利用する場合、以下の問題が起こると考えられる。

ログにホスト名ではなくIPアドレスが記録されるようになる
ホスト名に基づく認証に失敗するようになる

これらの問題は致命的ではない。また、ip6.int のみを引くリゾルバは少数派であり、さらにサーバに利用されているものとなると、数は少ないと考えられる。

背景

1995年12月に発行された RFC 1886で、IPv6 の逆引きに ip6.int を利用することが定められた。

2001年8月に発行された RFC 3152で、ip6.int の代わりに ip6.arpa を利用することが定められた。理由は、IAB の声明を参照のこと。 2005年8月の RFC 4159 では、 2005年9月1日以降 RIR は ip6.int を保守する必要はないと述べられている。

すべての RIR は、ip6.int 以下で権威を持つドメインの保守を2006年6月1日に停止する。

余談ではあるが、6bone の廃止は2006年6月6日だと RFC 3701で定められている。

決定事項

以下のことが決定している。

RIR は、次のことを ip6.int の管理者に通知。すなわち、 ip6.int 以下で、 RIR が管理するIPv6アドレスの逆引きに対応するドメインについて、RIR への委譲を決定日に止めること
RIRは、管理しているIPv6アドレスの逆引きに対応するip6.int以下のドメインを運用しているDNSサーバから削除

なお、APNIC 20 の DNS SIG での発表も参考にされたい。

統計

APNIC が管理する ip6.int 配下のドメインに対し、query は毎分 5 個程度である。

WIDE が管理している DNS での統計は以下の通りである。期間は、2005年12月30日 05:00から2006年1月20日 03:20。 ip6.int への query は、毎分3.8個程度である。

WIDE での統計(実数)
Transport/Zone	int	arpa	int+arpa
IPv4	109,273	366,474	475,747
IPv6	5,211	6,023	11,234
IPv4+IPv6	114,484	372,497	486,981

WIDE での統計(百分率)
Transport/Zone	int	arpa	int+arpa
IPv4	22.4%	75.3%	97.7%
IPv6	1.1%	1.2%	2.3%
IPv4+IPv6	23.5%	76.5%	100%

アドレスの割り当て

IANA から RIR への IPv6 アドレスの割り振りは、IANA のページに載っている。

考察

以下の理由により、逆引きにかかる時間は短くなり、改善されると予測できる。

おおざっぱに言えば、RIR が管理するIPv6アドレスの逆引きに対応する ip6.int以下の名前を引くと、常に name error (NXDOMAIN) が返るようになる。
LAME が新たに発生するとは考えにくい。 LAMEはむしろ減ると考えられる。なぜなら、RIRレベルの上位ドメインで name error が無条件に返るようになるため、中途半端に管理されることが多い下位ドメインの悪影響を受けにくくなるから。

リゾルバ

リゾルバには以下の4種類がある。

「int のみ」引くリゾルバ
「arpa のみ」引くリゾルバ
「int → arpa」と引くリゾルバ
「arpa → int」と引くリゾルバ

それぞれのリゾルバが検索できる範囲が、ip6.int の廃止の前と後で、どのように変化するのか、以下の表にまとめる。行は、ゾーンを示す。たとえば、"int,arpa" は、ip6.int と ip6.arpa 両方にゾーンが設定されていることを示している。列はリゾルバの種類を意味する。 "o" は検索可能、"x" は検索不能、"/" の左側が ip6.int 廃止前、右側が廃止後を示す。

リゾルバ/ゾーン	int	arpa	int,arpa	なし
int のみ	o/x	x/x	o/x	x/x
arpa のみ	x/x	o/o	o/o	x/x
int → arpa	o/x	o/o	o/o	x/x
arpa → int	o/x	o/o	o/o	x/x

変化を知るには、この表で "/" の左と右が異なるものを考えればよい。

ip6.arpa に登録されず、ip6.int のみに登録されているアドレス("int" の列) が検索できなくなるが、これは設定ミスであるので、直すしかない。問題は、int のみ引くリゾルバが、まったく逆引きできなくなることである。

それぞれのリゾルバに対する考察を以下に示す。

int のみ引くリゾルバ
- 変化：まったく逆引きができなくなる
- 問題あり
arpa のみ引くリゾルバ
- 変化：なし
- 問題なし
int → arpa と引くリゾルバ
- 変化：ip6.intのみに登録されたレコードが引けなくなる
- 変化：ip6.intとip6.arpaで登録内容が違う場合、返り値が変わる
- 問題なし
arpa → int と引くリゾルバ
- 変化：ip6.intのみに登録されたレコードが引けなくなる
- 問題なし

リゾルバの調査結果

FreeBSD (src/lib/libc/net/name6.c)
- 4.7以前: int のみ [問題あり]
- 4.8 - 4.10: arpa → int
- 4.11以降: arpa のみ
- 5.0 - 5.2: arpa → int
- 5.3以降: arpa のみ
NetBSD (src/lib/libc/net/gethnamaddr.c)
- 1.5, 1.6: arpa → int。
  - ただし、ブランチを最新にすると arpa のみになるようだ。
- 2.0以降: arpa のみ
OpenBSD (src/lib/libc/net/gethostnamadr.c)
- 3.1以前: int のみ [問題あり]
- 3.2-3.5: arpa → int
- 3.6以降: arpa のみ
Linux (glibc) (resolv/nss_dns/dns-host.c)
- 2.0 - 2.0.6: int のみ [問題あり]
- 2.1 - 2.1.3: int のみ [問題あり]
- 2.2 - 2.2.4: int のみ [問題あり]
- 2.2.5: arpa (nibble)のみ
- 2.3 - 2.3.2: arpa (nibble) → int
- 2.3.3: arpa (bitlabel) → int [問題あり]
- 2.3.4 - 2.3.6: arpa (bitlabel) → arpa (nibble) → int
Linux (uClibc) (libc/inet/resolv.c)
- (0.9.28の時点で)すべて: int のみ [問題あり]
Windows
- IPv6 Technology Preview for Windows 2000: int のみ [問題あり]
- Windows XP: int のみ [問題あり]
- Windows XP (fully updated): arpa のみ
- Windows Server 2003: int のみ [問題あり]
- Windows Server 2003 (fully updated): arpa のみ
- Windows Vista: arpa のみ
MacOS X: 調査中
- 10.3.9のsshdでは arpa のみ
Solaris
- Solaris 8: int のみ [問題あり]
  - Solaris 9に対するものと同様のパッチ(下記参照)がip6.int廃止の日までに提供される予定
- Solaris 9: int のみ [問題あり]
  - Solaris9の挙動については、Solaris10と同じようにするパッチあり: patch 112970-04 (sparc), patch 114354-02 (x86)
- Solaris 10: arpa => int

リゾルバとサーバ

逆引きを利用するのは、主にサーバである。主な用途は以下の通りである。

ログを取る
認証に利用する
- 逆引きの存在を確かめる
- 正逆の一致を確かめる

int のみを引くリゾルバをサーバが利用している場合、以下の問題が起きると考えられる。

ログにホスト名ではなくIPアドレスが記録されるようになる
ホスト名に基づく認証に失敗するようになる

フィールド実験

WIDE プロジェクトでは、 ip6.int を擬似的に廃止する環境を作り、その環境で生活するというフィールド実験を実施している。

具体的には、IP アドレスのある範囲から、 WIDE が管理する ip6.int 以下の名前に対し問い合わせがあった場合、 name error を返すように設定した。実験を開始したのは、2006年1月18日である。

実施前から分かっていたが、この実験に対する評価は難しい。それを承知で結論を述べると、これまで問題は発見されてない。これが ip6.int を廃止しても致命的な問題は起こらないことの完全な証明にはならないが、問題がそう多くは起こらないことを示唆していると考えられる。

スケジュール

2005/11/18 キックオフミーティング (done)
2006/12/17 WIDE 研究会 (done)
2006/01-02 実証実験 (実施中)
2006/03/01 APNIC 21 IPv6 Technical SIG で報告 (done)
2006/03/17 JPNIC から ISP へアナウンス (done)
2006/06/01 ip6.int 廃止