An Investigative Report Regarding Hotel Internet Connection Environments

Overview

In recent years, Internet connections are made available to customers in a lot of hotels. In most cases, connections are limited to IPv4 service, and IPv6 is not available. On the other hand, many newer operating systems support IPv6 and the number of system running a dual stack node has increased dramatically. Operating a dual-stack node on a network where only IPv4 is available is a necessity due to the time it takes to migrate from IPv4 to IPv6. In theory, there shouldn't be any issues. It is understood that the problems are due to issues with certain IPv4 environments that have IPv6 enabled. This document describes the information on equipment with which we observed these issues, and DNS implementations that were investigated as examples of the problems.

Information about Equipment which displays problems

The table below shows equipment with which problems are observed. The equipment shown here is only a subset of equipment in which the problems are observed and it is not guaranteed that the problems do not occur in other equipment. Firmware/Internal Software updates for equipment shown below may solve some or all of the issues witnessed.

Example scenario that shows the problem

In this section we will explain the problems seen when trying to connect to the internet through a Hotel Internet connection with an IPv6 enabled operating system. For this scenario, we do not know whether or not the system in use at the hotel is one of the systems listed in the table in the previous section.

The hotel provided material which instructs the user to uninstall IPv6 from Windows XP if they are experiencing problems. That being said, with the increase in the number of users, the instances of people running into this problem will increase.

Test Environment

The following operating systems listed below were used to test Internet connection.

• Windows XP SP2
• Linux2.6
• MacOS X 10.4.1
• FreeBSD5.4-RELEASE

In the hotel where the test was executed, you are required to use a Web-based authentication system when connecting the Internet. In the room, an Ethernet connection jack is available, and DHCP auto configuration is enabled. When connecting computer to the network and accessing a Web page (any page), a service agreement confirmation is displayed, and once accepted, the service becomes available and the page is displayed.

Test Results

Test results are shown below.

Explanation of phenomenon

When trying to connect to the hotel system and display a Web page (any page), a service agreement confirmation screen is displayed. When you click on the acceptance button for the agreement, you are automatically connected to the authentication system and the computer connection is set to be able to connect to the Internet. Until the accept button is clicked, the browser is blocked and only the service agreement page is enabled. If you open other browser instances, you are redirected to the service agreement confirmation page.

When we observed the packets being exchanged, the problem with Windows XP SP2 occurs for the following reasons:

• The Internet connection system in the hotel returns a specific A response to the DNS resource record which doesn't exist.
• Windows XP SP2 accepts it even though the type of resource record that is queried to DNS and the type of which is returned as a response don't match. For example, when an A response is returned against an AAAA query, the A response is accepted.

Following is a detailed explanation of the phenomenon observed based on the output result of the tcpdump command.

1. The computer is connected to the hotel LAN (it is actually a cable modem).
2. The private address is obtained from DHCP. At this point, IPv4 DNS server address (i.e. 172.31.0.1) is received by DHCP.
3. Access some Web pages. For example, it accesses http://v6fix.net/.
4. The AAAA record of v6fix.net is queried to 172.31.0.1.

        44   5.315060 172.31.0.116 -> 172.31.0.1
          DNS Standard query AAAA v6fix.net
   

   As a result of this inquiry, the following response is returned.

        45   5.358404   172.31.0.1 -> 172.31.0.116
          DNS Standard query response AAAA 2001:200:1b0:1000:203:47ff:fe3f:d15
   

   Because the global IPv6 address is not assigned to the computer, the connection to the address obtained by the AAAA response fails, and the fall back to the A query is executed.

        46   5.359035 172.31.0.116 -> 172.31.0.1
          DNS Standard query A v6fix.net
   

   As a result, following response is returned and it moves on to 5.

        47   5.402664   172.31.0.1 -> 172.31.0.116
          DNS Standard query response A 203.178.140.19
   

5. At this point, because it turns out that the address of v6fix.net is 203.178.140.19,HTTP GET is issued to 203.178.140.19

        51   5.412318 172.31.0.116 -> 203.178.140.19
          HTTP GET / HTTP/1.1
   

6. 5. is intercepted and an HTTP OK for displaying the service agreement confirmation screen is returned. The content is as follows.

        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. The user is redirected to http://registration.test.example.jp by Java script included in the response. In order to display the destination of the redirect, the AAAA record of registration.test.example.jp is queried.

        58   5.552679 172.31.0.116 -> 172.31.0.1
          DNS Standard query AAAA registration.test.example.jp
   

   The following response is returned.

        59   5.585076   172.31.0.1 -> 172.31.0.116
          DNS Standard query response A 172.31.0.1
   

   DNS system used in this hotel always returns a specific A response (in the above example, 172.31.0.1). Additionally, Windows XP SP2 accepts an A response which is returned for an AAAA inquiry, and stops inquiring at this point. As a result, a correct A response is not obtained.
8. HTTP GET to 172.31.0.1.
9. Returns to 6.

On Linux, MacOSX and FreeBSD, A response returned to AAAA inquiry is not used and only A response returned to A inquiry is used. Therefore, it works without issue even though the response from the DNS on the hotel side doesn't agree with the type of resource record queried.

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