KDDI R&D Laboratories (KDDI Lab), a group company of a major Japanese service provider, engages in various research activities on communications. In September 2004, the company switched to IPv6 only networking for most of its internal operations at the lab, severely limiting the use of IPv4. This is not a time-limited trial, but a transition of real, production netweok. The attempt involved many challenges.
It was the decision by Toku Asami, the president of the lab, to move the network of about 200 nodes at its headquarters in Kamifukuoka City, Saitama Prefecture of Japan. Internal network of the site has been enabled for IPv4/IPv6 dual protocol, for several years then. The lab had given IPv6 support to Internet servers including DNS, mail, and Web, but IPv6 had only been used by nodes involved in IPv6-related researches. Most nodes had only been installed with IPv4.
“It is not strange for a company trying to develop new services with IPv6 not to use IPv6 for its own operation,” thought Asami. That was the beginning of the lab’s project to move its network to IPv6.
Just adding IPv6 protocol to computer nodes to make them dual stack would only end up allowing nodes on the network to use IPv4. KDDI Lab, therefore, decided to switch all general PC nodes to IPv6 only environment. Almost all user nodes in the lab had been using Windows family, including Windows 2000 and Windows 98. Some researchers use UNIX or Linux, but they also use Windows PCs for company documents processing and other reasons, and they remotely runs UNIX and Linux applications. The lab unified all Windows platform to Windows XP, and enabled IPv6 only. These nodes conduct daily business operations with Web, e-mail and FTP.
 [0] |
| KDDI Lab network before move to pure IPv6 |
 [0] |
| KDDI Lab network after move to pure IPv6 |
Internet service servers on DMZ segment had already been running dual stack, which were left as they were. General nodes would access DNS and e-mail servers by IPv6. Some user segments had DNS and e-mail servers, and they were re-configured to use IPv6 only.
But it is very difficult to force applications for back office sections to support IPv6. Therefore, those nodes which require use of IPv4 business applications were moved to an IPv4-only VLAN segment.
Almost all Web servers on the Internet support IPv4 only. In order to enable access to these servers from IPv6 nodes, the lab placed a NATPT-type IPv4/IPv6 translator at the Internet boundary.
KDDI Lab had run Cisco VPN (IPsec) for remote access from outside to internal network. With the switch of its network to IPv6, the lab placed an ISATAP router to enable dynamic IPv6 over IPv4 tunneling for remote access users.
Server-related issues and solutions
With business applications limited to Web, e-mail, and FTP, the move to IPv6 does not present serious obstacles to the daily business operations now. But the lab encountered many challenges in the initial stage of transition. Server-related challenges were as follows.
- sendmail spam check
KDDI Lab uses sendmail for e-mail server software, and runs check_mail for checking the senders, in order to counter spam mails. At first, “the routine rejected mails from the servers registered to DNS server with AAA record (IPv6 address) but without A record (IPv4 address),” says Takahiro Kubo, Senior Manager, Advanced Focus Technology Laboratory at KDDI R&D Lab. Of course, all mail servers currently on the IPv4 Internet has IPv4 address registered to DNS. The mail server in question was an internal one placed on IPv6-only VLAN segment. The lab solved this problem by registering a temporary IPv4 address as A record to DNS.
- The issue with DNS and translator in IPv4 Web access
Some of DNS servers currently on the Internet do not respond to AAAA queries with “no AAAA record” reply. They just remain silent. Internet Explorer and other Web browsers with IPv6 support try to make Web access on IPv6 first, by querying DNS on AAAA record, when users enter URLs. When DNS returns “no AAAA record” message, then the browser tries IPv4 access by querying A record. If a DNS does not reply to the query, the browser has to be waiting until it finally times out by itself. This issue has come to be widely known recently. WIDE Project, for example, started its effort to improve the situation through IPv6 FIX activities (http://v6fix.net/ [1]).The issue cannot be fundamentally solved without improvement on this DNS issue. But “we are adjusting the configuration of the translator to shorten AAAA record waiting and quick switch to A record query,” said Mikio Abe, research engineer at Advanced Focus Technology Laboratory.
KDDI Lab nodes access IPv4-only Web servers through NATPT-type IPv4/IPv6 translator. Even if the translator encounters such DNS and has to wait for a while, it can eventually make query on IPv4 address, translates the acquired IPv4 address to IPv6 address, gives the IPv6 address to the user node, and holds the address translation table entry for predefined period of time. But the entry is erased when it reaches the time limit, resulting in a long waiting period again and Web browser time-out. Specifically, some users could not complete a Web form entry because of the time-out.
- Web contents with IPv4 addresses hard-coded
A small number of Web servers have IPv4 address hard-coded as link address. “A user could not see the send mail button of hotmail because the button had IPv4 address as link address,” says Kubo. Fundamental solution in this case is ask the Web master to use FQDN. But the lab is currently coping with this issue by Web proxy. (Hotmail later corrected the URLs in question to FQDN.)
- Path MTU Discovery Blackhole issue
KDDI Lab had used Cisco VPN for remote access from outside to internal network. The company combined ISATAP with this to enable IPv6 remote access. In other words, with the transition of internal network to IPv6-only, the lab decided to capsule IPv6 packets in IPv4 packets, which in turn are capsuled by Cisco VPN. Default MTU for Cisco VPN router is 1460. Router Advertisement (RA) packets from ISATAP server were sent with MTU size 1460, too. This means that the size of RA packets exceed Cisco VPN MTU, causing Path MTU Discovery Blackhole, stopping Web and other communications. Therefore, the company changed ISATAP router configuration so that RAs are sent with MTU of 1280.
- ISATAP batch file
The lab made a batch file available to remote access/ISATAP users for specifying ISATAP server and MTU size. Users login with VPN first, and then execute the batch file. But in practice, users sometimes cannot get IPv6 address at the first attempt. “We first asked them to use commands to confirm the IPv6 address, but it was cumbersome and users didn’t like that. We later found that IPv6 address is automatically created by registering ISATAP server to DNS with the “ISATAP” string combined with primary domain name. As a result, users only need to launch Cisco VPN client and make connection now,” says Kubo.