ホテル接続環境に関する調査報告

執筆:WIDE v6fix WG
編集:島慶一
作成:2006年1月5日
更新:2006年2月23日

概要

近年、多くのホテルでインターネット接続環境が提供されるようになった。 ほとんどの場合、接続はIPv4サービスに限定されており、IPv6は利用できない。 一方、最近のオペレーティングシステムはIPv6をサポートしているものも多く、 デュアルスタックノードとして動作するシステムも増えてきた。IPv4のみが提 供されたネットワークでデュアルスタックノードを運用するという環境は、 IPv4からIPv6への移行期間に必ず発生する状況であり、理論上問題が発生する ことはない。しかし、一部の環境ではIPv6の機能を有効にする事で、IPv4の接 続に問題が発生することがわかっている。本文書では、問題が観測された機器 情報と、問題の原因の一例として調査したDNS実装の動作を解説する。

問題のある機器情報

以下の表に問題が観測された機器を示す。ここに示した機器は、実際に問題 が観測された機器のみであり、表に示した機器以外では問題が発生しないこと を保証するものではない。また、示した機器に関しても、内部ソフトウェアの 更新などによって、問題が解決している場合もあると考えられる。

問題の発生が確認された機器
機器名 公開日付 概要 解決方法
GuestLINKとWindows XP 2005/04/04 ホテルインターネット接続用ルータとしてAtreus Systemsから提供されて いるGuestLINKのウェブベースの認証システムは、IPv6を有効化したWindows XPとの組み合わせで問題が発生する。この組み合わせではWindows XPはインター ネット接続できない。ただし、認証システムを経由しないよう設定されている 場合(認証なしでインターネット接続が利用できるように設定されている場合) 、IPv4/IPv6デュアルスタックのウェブサーバには問題なくアクセスできる ことが確認されている。 ipv6 uninstallでIPv6モジュールを削除する。
HSG-1000とWindows XP 2005/04/04 ホテルインターネット接続用ルータとしてNomadix, Inc.から提供されてい るHSG-1000のウェブベースの認証システムは、IPv6を有効化したWindows XP と の組み合わせで問題が発生する。この組み合わせではWindows XPはインターネッ ト接続できない。 ipv6 uninstallでIPv6モジュールを削除する。
ISS-2000とWindows XP 2005/04/04 ホテルインターネット接続用ルータとしてHandlink Technologies Inc.か ら提供されているISS-2000のウェブベースの認証システムは、IPv6を有効化し たWindows XP との組み合わせで問題が発生する。この組み合わせではWindows XPはインターネット接続できない。 ipv6 uninstallでIPv6モジュールを削除する。

問題の一例の紹介

本節では、IPv6を有効化したオペレーティングシステムでホテルのインター ネット接続サービスを利用し、問題の原因を調べた結果をまとめる。現時点で は、調査したホテルで利用されているシステムが前節で紹介した機器のいずれ かを用いているのか、表に挙げられていない機器を利用しているのかは不明で ある。

調査したホテルには、インターネット接続サービス利用の手引きの一部と して、Windows XPを使う場合にIPv6をアンインストールするように指示する資 料が備え付けられていた。すなわち、少なからぬ利用者が、この問題に遭遇し ていると思われる。

テスト内容

以下に示した各種オペレーティングシステムでインターネット接続サービス を利用する。

テストを実施したホテルでは、インターネットに接続する際にウェブベース の認証システムを利用する必要がある。部屋にはイーサネット接続口が用意さ れており、DHCPを用いた自動設定によりインターネットサービスを利用する仕 組みになっている。コンピュータを接続し、ウェブページ(任意のページ)にア クセスすると、サービス規約確認のページが表示され、規約を承諾するとサー ビスが利用できるようになる。

テスト結果

テスト結果は以下の通りとなった。

テスト結果
Windows XP SP2 接続不可(サービス確認画面から先に進めない)
Linux2.6 問題なし
MacOS X 10.4.1 問題なし
FreeBSD5.4-RELEASE 問題なし

現象の解説

ホテルのシステムに接続し、ウェブページ(任意のページ)を表示しようとす ると、サービス規約の確認画面が表示される。承諾ボタンを押すと、認証シス テムに接続され、接続したコンピュータがインターネットに接続できるように 設定される。承諾ボタンを押すまで、確認画面以外のページは表示できず、ど のページにアクセスしてもすべて確認画面に転送される。

パケットのやり取りを観測した結果、Windows XP SP2では以下の理由により 問題が発生することが判明した。

以下、実際のやりとりから得られたtcpdumpの出力結果を元 に、詳細な現象を順を追って解説する。

  1. ホテルのLAN(実際はケーブルモデム)にコンピュータを接続する。
  2. DHCPでプライベートアドレスを取得する。ここで、DHCPによりIPv4 DNSサー バのアドレス(例:172.31.0.1)をもらう。
  3. ブラウザで、どこかのウェブページを表示しようとする。例えば http://v6fix.net/にアクセスする。
  4. 172.31.0.1に対して、v6fix.net のAAAAを問 い合わせる。 
         44   5.315060 172.31.0.116 -> 172.31.0.1
       DNS Standard query AAAA v6fix.net
    問い合わせの結果、以下の応答が返る。 
         45   5.358404   172.31.0.1 -> 172.31.0.116
       DNS Standard query response AAAA 2001:200:1b0:1000:203:47ff:fe3f:d15
    コンピュータにはグローバルIPv6アドレスは割り当てられていないので、AAAA 応答で入手したアドレスへの接続は失敗し、A問い合わせにフォールバックす る。 
         46   5.359035 172.31.0.116 -> 172.31.0.1
       DNS Standard query A v6fix.net
    その結果、以下の応答が返り、5.へ進む。 
         47   5.402664   172.31.0.1 -> 172.31.0.116
       DNS Standard query response A 203.178.140.19
  5. この時点で、v6fix.netのアドレスが 203.178.140.19であることがわかったので、 203.178.140.19に対してHTTP GETを発行する。 
         51   5.412318 172.31.0.116 -> 203.178.140.19
       HTTP GET / HTTP/1.1
  6. 5. のリクエストは横取りされ、サービス規約確認画面を表示するため のHTTP OKが返る。内容は以下の通りである。 
         53   5.493634 203.178.140.19 -> 172.31.0.116
       HTTP HTTP/1.0 200 OK (text/html)
       <HTML>
       <!-- This file is generated by /usr/sbin/gl_nwconfig -->
       <HEAD>
       <meta httpd-equiv="Cache-Control" content="no-cache"; http-equiv="Content-Type" content="text/html" meta httpd-equiv="Pragma" content="no-cache">
       </HEAD>
       <BODY onload="open('http://registration.test.example.jp', target='_self')">
       </BODY>
       <HTML>
  7. 応答に含まれるJavaスクリプトによって、ユーザは http://registration.test.example.jpにリダイレクトされる。 リダイレクト先を表示するため、registration.test.example.jp のAAAAを問い合わせる。 
         58   5.552679 172.31.0.116 -> 172.31.0.1
       DNS Standard query AAAA registration.test.example.jp
    その結果、以下の応答が返る。 
         59   5.585076   172.31.0.1 -> 172.31.0.116
       DNS Standard query response A 172.31.0.1
    このホテルで利用されているDNSシステムは、存在しないリソースレコードの 問い合わせに対し、常に特定の (上記の例では172.31.0.1) A応 答を返送する。さらに、Windows XP SP2 は、AAAA問い合わせに対して返信さ れたA応答を受理し、ここで問い合わせをやめてしまう。結果、正しいA応答を 得られない。
  8. 172.31.0.1にHTTP GETする。
  9. 6. に戻る。

Linux、MacOSX、FreeBSD では、AAAA問い合わせに対して返ってきたA応答 を利用せずに、A問い合わせに対して返ってきたA応答のみを利用する。そのた め、問い合わせたリソースレコードの種類に合致しない応答がホテル側のDNS から返ってきても問題なく動作した。

Copyright (C) WIDE Project (2006). All Rights Reserved.