Network Working Group H. Hazeyama Internet-Draft NAIST Intended status: Informational Y. Ueno Expires: April 26, 2012 Keio Univ. October 24, 2011 Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011 draft-hazeyama-widecamp-ipv6-only-experience-00 Abstract This document discusses our experiences from the IPv6 only network experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The WIDE camp Autumn 2011 was held from September 6th to September 9th, 2011, with 153 participants.This document reports answers of questionnaire from participants, troubles and causes, with referring IETF's IPv6 only network experiences. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Hazeyama & Ueno Expires April 26, 2012 [Page 1] Internet-Draft Abbreviated Title October 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4 3. Network and Experiment Setup . . . . . . . . . . . . . . . . . 5 3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 6 3.1.1. External Links . . . . . . . . . . . . . . . . . . . . 7 3.1.2. IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. DHCP6 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.4. DNS64 and NAT64 . . . . . . . . . . . . . . . . . . . 8 3.2. The IPv4 Networks . . . . . . . . . . . . . . . . . . . . 8 3.2.1. The IPv4 Network through SA46T . . . . . . . . . . . . 8 3.2.2. The IPv4 Network through 4RD . . . . . . . . . . . . . 8 4. Experiences from the Experiments . . . . . . . . . . . . . . . 9 4.1. Answers of Questionnaire . . . . . . . . . . . . . . . . . 9 4.1.1. The distributions of connectivities that participants used . . . . . . . . . . . . . . . . . . 10 4.1.2. The satisfaction on the IPv6 only connectivity . . . . 10 4.1.3. The satisfaction on the network quality . . . . . . . 11 4.2. Reported Troubles . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Troubles on the IPv6 capability of OSes and Devices . 11 4.2.1.1. Pains due to long fallback routine . . . . . . . . 12 4.2.1.2. Pains due to lack of DHCP6 capability . . . . . . 12 4.2.1.3. Pains due to the OS's incapability on IPv6 only setting . . . . . . . . . . . . . . . . . . . 12 4.2.1.4. Pains due to the device's incapability for IPv6 . 12 4.2.1.5. Failure of settings through GUI . . . . . . . . . 12 4.2.2. Troubles on Applications . . . . . . . . . . . . . . . 12 4.2.2.1. Pains due to IPv6 incapability on applications . . 13 4.2.2.2. Failures due to incapability of protocol translation between IPv4 and IPv6 . . . . . . . . 13 4.2.2.3. Failures due to MTU mismatch problems . . . . . . 13 4.2.3. Troubles on Name Resolution . . . . . . . . . . . . . 13 4.2.3.1. Failures due to IPv4 address literals . . . . . . 14 4.2.3.2. Failures due to lack of reverse lookup entries on AAAA records . . . . . . . . . . . . . . . . . 14 4.2.3.3. Failures due to the lame delegation . . . . . . . 14 4.2.3.4. Pains due to the overload of DNS64 . . . . . . . . 14 4.2.3.5. Failures due to inappropriate AAAA replies . . . . 15 5. Lessons from the experiences on the WIDE camp . . . . . . . . 15 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. PMTUD, MTU mismatch problems . . . . . . . . . . . . . . . 16 6.2. Inappropriate AAAA replies . . . . . . . . . . . . . . . . 16 Hazeyama & Ueno Expires April 26, 2012 [Page 2] Internet-Draft Abbreviated Title October 2011 7. Conclusion and Future Work . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Hazeyama & Ueno Expires April 26, 2012 [Page 3] Internet-Draft Abbreviated Title October 2011 1. Introduction This document discusses our experiences from the IPv6 only network experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The WIDE camp Autumn 2011 was held from September 6th to September 9th, 2011, with 153 participants. The main purposes of our experiment in the WIDE camp were to grasp how much participants could live in the IPv6 only connectivity environment, and to clarify what kind problems would occurred on the operation through actual users' experiences of the IPv6 only connectivity brought by DHCP6 [RFC3736] and the 6to4 translation by DNS64 and NAT64. This document reports answers of questionnaire from 110 participants (71.9% of the whole participants), troubles reported to the NOC team and causes that the NOC team analyzed. Also, we refer to the IETF's IPv6 only network experiences [I-D.draft-arkko-ipv6-only-experience], we try to clarify new issues on IPv6 transition operation. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Technology and Terminology In this document, the following terms are used. "NAT44" refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663]. "Dual Stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213]. "NAT64" refers to a Network Address Translator - Protocol Translator defined in [RFC6052], [I-D.ietf-behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], [I-D.ietf-behave-dns64], [I-D.ietf-behave-ftp64]. "SA46T" refers to Stateless Automatic IPv4 over IPv6 Tunneling defined in [I-D.draft-matsuhira-sa46t-motivation], [I-D.draft-matsuhira-sa46t-as], [I-D.draft-matsuhira-sa46t-spec], [I-D.draft-matsuhira-sa46t-gaddr], [I-D.draft-matsuhira-sa46t-applicability], [I-D.draft-matsuhira-sa46t-mcast]. "4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure Hazeyama & Ueno Expires April 26, 2012 [Page 4] Internet-Draft Abbreviated Title October 2011 defined in [I-D.draft-murakami-softwire-4rd]. 3. Network and Experiment Setup The WIDE camp autumn 2011 was held at Mastushiro Royal Hotel in Nagano Prefecture of Japan from September 6th to September 9th, 2011. We set up the IPv6 only network as the main conference network connectivity. The conference network connectivity were mainly served as wireless networks. The served IPv6 only network was not a pure IPv6 only network because most participants had not IPv6 environment on his / her organization, yet. Therefore, we served an IPv6 connectivity with 6to4 translation mechanisms, that is, with NAT64 and DNS64. 153 participants joined in the conference and tried the IPv6 only connectivity through their own devices, such as Laptop PCs, smart phones, and so on at September 6th and 7th, 2011. Participants reported their experiences or troubles through questionnaire, emails, and / or directly claims to the NOC team. As a last resort for IPv4 only OSes or applications, we prepared a global IPv4 network through SA46T. From the afternoon of September 7th 2011, we additionally provided a private IPv4 network through 4RD. Hazeyama & Ueno Expires April 26, 2012 [Page 5] Internet-Draft Abbreviated Title October 2011 +--------+ +-----------+ |SA46T-GW|--(v4)----+ |v6tunnel-gw| | |--(v6)-+ | +-----------+ +--------+ | | |(v6) |(v6) +----------------------------------+ +---+ +-----------| router |--(dual)--|DNS| | +----------------------------------+ +---+ | | |(v6) |(v4) | | +--------+ (v6) (dual) | NAT64 | | | +--------+ | +---------+ +---------------+ | | WIDE BB |-(v4)-| IPv4 Internet | | +---------+ +---------------+ | |(v6) | +---------------+ | | IPv6 Internet | +---------+ +---------------+ |satellite| |(v6) +---------+ +-------+ | | ONU | | +-------+ | |(v6) | +-------------+ | | v6tunnel-gw | | +-------------+ | |(v6) | +--------+ +-----+ +-----------------| router |--(v6)--|DNS64| +--------+ +-----+ |(v6) | +-----+ +--------+ | +-----+ |DHCP4| |SA46T-GW| (v6) |DHCP6| +-----+ +--------+ | +-----+ |(v4) |(v4) | |(v6) ----------------- user access ----------------- The Basic Network Topology. Figure 1 3.1. The IPv6-Only Network Here, we explain the basic configurations on the IPv6-Only network on the WIDE camp. Hazeyama & Ueno Expires April 26, 2012 [Page 6] Internet-Draft Abbreviated Title October 2011 3.1.1. External Links Figure. 1 shows the basic network topology of the WIDE camp autumn 2011. We announced the IPv6 and IPv4 addresses on the conference network from the WIDE backbone's address block. The conference network had two IPv6-Only external lines; one was an IPv6-Only network through a portable satellite base station, the other was an IPv6 Internet service on a FTTH line. On the FTTH line, we set up an IPv6 tunnel between the hotel and Keio university Shonan Fujisawa Campus (SFC). The main user access VLAN was routed through this line, both the IPv6 network and the IPv4 network by SA46T. We tested two types of IPv6 services provided by NTT East as an access carrier, Internet MultiFeed as a virtual network enabler, and IIJ as an IPv6 ISP. The IPv6 network on the FTTH external line was served through Native method [YasudaAPRICOT2011]. From 2:00 PM of September 5th to 8:00 PM of September 6th (JST), we used a Flet' s Hikari Next with IPv6 option. The IPv6 address on the v6tunnel gateway were assigned from RA with /64 prefix. From 8:00 PM of September 6th (JST), we changed the setting of the external line service to a Flet's Hikari Next with IPv6 option and a Hikari phone option, for the 4RD experiment, as drawn in Figure 2. The differences brought by Hikari phone option were as follows; i) an additional home gateway was added, ii) the IPv6 address delegation method was changed from RA with /64 prefix length to DHCP6[RFC3736] with /48 prefix length. On the other hand, the satellite line directly connected between the router on the hotel and the router on SFC. The satellite line transferred another IPv6 network VLAN. 3.1.2. IPv6 Tunnel For the IPv6 routing by WIDE Project's IPv6 address block, we achieved an L2TP tunnel between the v6-tunnel gateway on the Matsushiro and that on SFC over the FTTH line. The v6-tunnel gateways were composed of Linux Debian squeeze (kernel 2.6.32) servers with our original L2TP for IPv6 implementation. 3.1.3. DHCP6 Global IPv6 addresses for users and the DNS64 address were provided through ISC's DHCP6 implementation [ISC-DHCP]. A user cloud automatically get the IPv6 connectivity through the IPv6 Router Advertisement Options for DNS Configuration[RFC6106], if the DHCP6 implementation on the user's device worked well. Otherwise, a user had to set up DNS64 address as a resolver by manual. Hazeyama & Ueno Expires April 26, 2012 [Page 7] Internet-Draft Abbreviated Title October 2011 3.1.4. DNS64 and NAT64 We used linuxnat64 [linuxnat64] as the NAT64 implementation. DNS64 was built by ISC bind 9.8-p4 [bind]. As shown in Figure 1, we placed a DNS64 server on the hotel, on the other hand, NAT64 severs were settled on SFC side. 3.2. The IPv4 Networks 3.2.1. The IPv4 Network through SA46T As a last resort for IPv6 incapable OSes, devices and applications, we prepared an global IPv4 network through SA46T. We used a software implementation of SA46T developed by Fujitsu and Keio university. To conduct the capability tests of NAT64, DNS64 and DHCP6, the global IPv4 network was served as an option. A global IPv4 address was assigned to a user's device by registering the device's MAC address on a registration web page. We hid the registration web page from participants until 1:00 PM of September 7th (JST) to pursue the capability tests of NAT64, DNS64 and DHCP6. 3.2.2. The IPv4 Network through 4RD We also held the capability test of 4RD implementations. On the midnight of September 6th, we reconstructed the external link as shown in Figure 2 to convey 4RD encapsulated packets. The 4RD-BR on the SFC side was composed of a vyatta 4RD implementation [vyatta-4RD]. On the hotel side, we used IIJ's SEIL 4RD implementation [SEIL] as 4RD gateway and 4RD-BR and 4RD-CE. We started the 4RD experiment to participants at 3:15 PM of September 7th (JST). The 4RD-CE provided a private IPv4 network by DHCP4 and an IPv6 network by RA. The resolver was served through the DHCP4 function of the 4RD-CE. Hazeyama & Ueno Expires April 26, 2012 [Page 8] Internet-Draft Abbreviated Title October 2011 +--------+ +-----------+ +---------+ |SA46T-GW|--(v4)----+ |v6tunnel-gw| +---(v4)--| 4RD-BR | | |--(v6)-+ | +-----------+ | +-(v6)--| (vyatta)| +--------+ | | |(v6) |(v6) | | +---------+ +----------------------------------+ +---+ +-----------| router |--(dual)-|DNS| | +----------------------------------+ +---+ | | |(v6) |(v4) | | +--------+ (v6) (dual) | NAT64 | | | +--------+ | +---------+ +---------------+ | | WIDE BB |-(v4)-| IPv4 Internet | | +---------+ +---------------+ | |(v6) | +---------------+ | | IPv6 Internet | +---------+ +---------------+ |satellite| |(v6) +---------+ +-------+ +---+ +-------+ +------+ | | ONU |-(v6)-|HGW|-(v6)-|4RD-BR |-(v6)-|4RD-CE| | +-------+ +---+ |(SEIL) | |(SEIL)| | +-------+ +------+ | +-------------+ | | | | v6tunnel-gw |--(v6)----+ ---user access--- | +-------------+ (v6 / private v4) | |(v6) | +--------+ +-----+ +-----------------| router |---(v6)---|DNS64| +--------+ +-----+ |(v6) | +-----+ +--------+ | +-----+ |DHCP4| |SA46T-GW| (v6) |DHCP6| +-----+ +--------+ | +-----+ |(v4) |(v4) | |(v6) ----------------- user access ------------------- The Network Topology with 4RD. Figure 2 4. Experiences from the Experiments 4.1. Answers of Questionnaire Here, we reports the answers of questionnaire about the experiments. Hazeyama & Ueno Expires April 26, 2012 [Page 9] Internet-Draft Abbreviated Title October 2011 4.1.1. The distributions of connectivities that participants used Table. 1 shows the distributions of used connectivities which participants answered. 30 participants (19.6%) surely lived in the IPv6 only connectivity with NAT64 / DNS64 during the all conference days. 7 participants, who used the v6 connectivity and the v4 connectivity through SA46T, were such participants who came to the NOC team in September 6th for the NOC team's help to be assigned the IPv4 connectivity. 33 participants, who replied that he / she used the IPv4 connectivity served by 4RD but did not use the IPv4 connectivity through SA46T, were such persons that needed the IPv4 connectivity but would not want to register his / her MAC address to be registered. 34 participants, who used both SA46T and 4RD IPv4 connectivity, would join the comparison test between SA46T and 4RD. +-------------------+--------------------------------+ | Connectivities | # of participants (percentage) | +-------------------+--------------------------------+ | v6 only | 30 (19.6 %) | | v6 only + SA46T | 7 (4.5 %) | | v6 + 4RD | 33 (21.5 %) | | v6 + SA46T + 4RD | 34 (22.2 %) | | avoidance to ans. | 6 (3.9 %) | | No response | 43 (28.1 %) | +-------------------+--------------------------------+ Table 1: The distributions of connectivities that participants used 4.1.2. The satisfaction on the IPv6 only connectivity Table. 2 shows the satisfaction of participants about the IPv6 only connectivity. Different from the expectation by the NOC team, 90 participants (58.8%) were satisfied in the IPv6 only connectivity. Especially, Windows 7 users and Mac OS X 10.7 (Lion) users were likely to reply good impressions because their DHCP6 functions worked well. On the other hand, older OS users, Layer 3 VPN users (IPSec, PPTP) and / or non-XMPP IM users were tend to escape into IPv4 connectivities. From the free comments on questionnaire, many users were surprised that the availability of the IPv6 only connectivity with NAT64 and DNS64 were much more comfortable than that they thought. Hazeyama & Ueno Expires April 26, 2012 [Page 10] Internet-Draft Abbreviated Title October 2011 +-------------------+--------------------------------+ | Satisfaction | # of participants (percentage) | +-------------------+--------------------------------+ | Very Comfortable | 19 (12.4 %) | | Comfortable | 52 (33.9 %) | | Satisfactory | 20 (13.0 %) | | Inconvenient | 13 (8.4 %) | | Unbearable | 3 (1.9 %) | | avoidance to ans. | 3 (1.9 %) | | No response | 43 (28.1 %) | +-------------------+--------------------------------+ Table 2: The satisfaction on the IPv6 only connectivity 4.1.3. The satisfaction on the network quality Table. 3 shows distributions of answers about the satisfaction on the total network quality. 92 participants (60.1 %) were satisfied with the quality on the conference network. Most of 15 participants, who answered inconvenient or unbearable, were such participants who had to log-in their companies or organizations' intranets through Layer 3 tunnels by IPv4 to read e-mails. +-------------------+--------------------------------+ | Satisfaction | # of participants (percentage) | +-------------------+--------------------------------+ | Very Comfortable | 14 (9.1 %) | | Comfortable | 57 (37.2 %) | | Satisfactory | 21 (13.7 %) | | Inconvenient | 13 (8.4 %) | | Unbearable | 2 (1.3 %) | | avoidance to ans. | 3 (1.9 %) | | No response | 43 (28.1 %) | +-------------------+--------------------------------+ Table 3: The quality on the network 4.2. Reported Troubles Here, we summarize the reported troubles on the availability on the IPv6 network and IPv4 networks through SA46T and 4RD. 4.2.1. Troubles on the IPv6 capability of OSes and Devices Reported troubles on the IPv6 capability of OSes were as follows. Hazeyama & Ueno Expires April 26, 2012 [Page 11] Internet-Draft Abbreviated Title October 2011 4.2.1.1. Pains due to long fallback routine Most commercial OSes checked IPv4 connectivity when the IPv4 property were enabled. The fallback routine spent a few minutes. Many participants claimed why the initial network setting consumed a few minutes and how to solve it. The long fall back routine was easily solved by turning off the IPv4 property on each OS. The NOC team provided several manuals for turning off / turning on the IPv4 property in several OSes. 4.2.1.2. Pains due to lack of DHCP6 capability Older version OSes such as Mac OS X 10.6 (snow leopard) and older did not have DHCP6 capability. Such users had to set up the DNS64 resolver address in manual. Several novice users were bothered with setting up the DNS resolver settings and requested the NOC team support to set up it. 4.2.1.3. Pains due to the OS's incapability on IPv6 only setting Windows XP could not work without the IPv4 property, therefore, Windows XP users had to set up a local proxy to resolve AAAA records through IPv4 localhost IPv4 address (127.0.0.1). These settings were difficult for most Windows XP users, many participants were tend to give up the IPv6 settings. Several participants contributed TIPS or setting instructions for such Windows XP users. Android OS needed the IPv4 property on resolving names. 4.2.1.4. Pains due to the device's incapability for IPv6 Several devices, such as Apple's USB RJ45 Ethernet Port, did not have the IPv6 capability. Also, some participant reported he had to reinstall device drivers again and again. 4.2.1.5. Failure of settings through GUI Some Mac Book Air user met the IPv6 settings disappeared in a few minutes after he set the IPv6 settings through GUI. Also, Think Pad' network setting manager could not set up IPv6 only setting through GUI appropriately. These failure of settings could be solved by setting through CLI commands. 4.2.2. Troubles on Applications Three kinds of troubles on applications were reported to the NOC team. Hazeyama & Ueno Expires April 26, 2012 [Page 12] Internet-Draft Abbreviated Title October 2011 4.2.2.1. Pains due to IPv6 incapability on applications As well as Arkko's report on IETF IPv6 only connectivity experiments [I-D.draft-arkko-ipv6-only-experience], most non-XMPP based IM applications and VoIP applications did not work. Skype and Window live messenger users claimed to the NOC team that they wanted or had to use such IMs in their business. Several applications on Windows did not work, such as CVSNT, NOD32 signature updates. In Mac OS X, non-COCOA framework applications did not work well. On the other hand, Most HTTP/XMPP based applications or communications were available or worked well, expect for such HTTP/ XMPP based applications that might use IPv4 literals. 4.2.2.2. Failures due to incapability of protocol translation between IPv4 and IPv6 IPSec-based applications, such as OpenVPN or Apple Mobile Me IPSec and PKI based communications, did not work on the 6to4 connections. PPTP clients did not work, too. Also, some FTP clients did not work well on the v6 only connectivity with NAT64 / DNS64 and on the 4RD IPv4 connectivity. 4.2.2.3. Failures due to MTU mismatch problems During the setup on Sep. 5th, the NOC team met MTU problems. Several servers were hosted on the cloud (KVM) environment on the WIDE backbone (the WIDE Cloud). Basically, the WIDE Cloud backbone MTU size was set 9000 for rapid live migration, however, MTU 9000 setting on KVM hyper-visors collapsed various communications in the set up day (Sep. 5th). Therefore, we set the MTU size of KVM hyper-visors to 1500. According to answers of questionnaire and reported troubles, various UDP based communications, such as a Remote KVM function of CISCO UCS server, did not still work well by MTU mismatch problems, not only on the NAT64 / DNS64 environment, but also on the SA46T's 464 encapsulation. The NOC team could not find the actual MTU mismatch points during the conference days. 4.2.3. Troubles on Name Resolution The NOC team met several troubles on Name Resolution. Some of them were derived from typical mis-configurations. Hazeyama & Ueno Expires April 26, 2012 [Page 13] Internet-Draft Abbreviated Title October 2011 4.2.3.1. Failures due to IPv4 address literals As well as Arkko's report on IETF IPv6 only connectivity experiments, failures due to IPv4 address literals occurred. Many participants claimed they could not access to their IPv4 servers by IPv4 address literals through HTTP, SSH, VNC, IPSec, PPTP, IMAP, SMTP, and so on. Some of them were fixed by changing IPv4 address literals to name literals on the settings of their applications and / or by registering their IPv4 servers in DNS records. However, most of participants were not the administrators of their IPv4 servers or DNS servers. Thus, most of them escaped to the IPv4 connectivity served from the afternoon of Sep. 7th. On the VNC, PPTP, IPSec and other VPN communications, many participants claimed that several applications did not work well both on IPv4 only servers and on IPv6 capable servers even when they changed the access manners to name literals. Those access failures might be affected by incapability for IPv6/IPv4 translation on VPN protocols or MTU mismatch problems against UDP based communications. 4.2.3.2. Failures due to lack of reverse lookup entries on AAAA records In the hot stage days, the NOC team detected several commercial web pages could not be accessed due to failure of reverse lookup. Therefore, we registered all reverse lookup AAAA records on the camp.wide.ad.jp domains. 4.2.3.3. Failures due to the lame delegation As mentioned above, some commercial web sites required the reverse lookup in AAAA records as well as in A records. Several participants claimed some commercial web pages cloud not be seen by failure of reverse lookup, although we registered all reverse lookup entries in AAAA about the camp.wide.ad.jp domain. We investigated the causes of the failure of reverse lookup, the cause was the lame delegation on the upper authoritative server of the DNS64 server (ns.wide.ad.jp) brought by a mis-configuration of bind. After the lame delegation was solved by an operator of ns.wide.ad.jp, problems on reverse lookup were fixed. 4.2.3.4. Pains due to the overload of DNS64 In September 8th, the NOC team changed the configuration of DNS64 to enable DNSSEC functions. After enabling DNSSEC, the DNS64 server, which was placed on a KVM virtual machine on the Matsushiro Royal hotel, was overwhelmed by handling many queries and key verifications. Then, participants hardly accessed to IPv4 Internet with DNS64. Hazeyama & Ueno Expires April 26, 2012 [Page 14] Internet-Draft Abbreviated Title October 2011 Therefore, the NOC team moved the DNS64 server from the KVM environment to a physical server, then, the overload on the DNS64 server was solved. 4.2.3.5. Failures due to inappropriate AAAA replies Different from the IETF's experiment, the accessibility test of web pages were conducted by manual, that is, by actual web access of participants. Some web pages, especially search result pages of travel reservation sites, could not access from the IPv6 network through NAT64 / DNS64 translation. The reasons why connections to such web pages failed were derived from inappropriate DNS replies mentioned in [RFC4074]. We observed ``Return Name Error'' mentioned in Section 4.2 of [RFC4074], ``Return Other Erroneous Codes'' in Section 4.3 of [RFC4074], and Return a Broken Response in Section 4.4 [RFC4074], respectively. We could not solve these problems in the conference days because these problems were derived from wrong behaviors of DNS resolvers on the web sites. 5. Lessons from the experiences on the WIDE camp Here, we describe lessons or recommendations from the experiences on the WIDE camp for building or living in an IPv6 environment with NAT64 and DNS64. o You SHOULD implement or enable the IPv6 capability into your site soon if it is possible, because NAT or NAPT environments might cause various problems such as MTU mismatch, low throughput, incapability on translation, and so on. Actually, some partner organizations of the WIDE project requested IPv6 address blocks soon after the WIDE camp. o You SHOULD update or purchase OSes on your computers to the latest version, because Window 7 users and Mac OS X 10.7 (Lion) users did not meet critical troubles, and because older OS users met various troubles. o You WOULD be better to register reverse AAAA lookup entries, because several commercial web sites require the reverse lookup. o You SHOULD give sufficient resources to a DNS64 server, because the failure or overload of DNS64 server are critical for the accessibility to IPv4 Internet from IPv6 only network. Hazeyama & Ueno Expires April 26, 2012 [Page 15] Internet-Draft Abbreviated Title October 2011 o You SHOULD check whether your web / DNS appliances return inappropriate AAAA replies or not, because some web appliances might return inappropriate AAAA replies and inappropriate AAAA replies can be solved by only administrators on web sites. o You SHOULD take care of MTU size on multiple overlaid underlay networks because PMTUD might not work in some times. 6. Open Issues 6.1. PMTUD, MTU mismatch problems On the camp-net experiments, PMTUD, MTU mismatch problems occurred in several points. The NOC team and experiment team could not completely fix all MTU mismatch problems, therefore, several participants could not use UDP communications, such as a remote KVM function of a CISCO UCS server, through the conference network or VPN tunnels. These problems were mainly derived from the failure of Path MTU Discovery. In the operational problem to avoid the overload of routers or DDoS attacks, man y networks turn off PMTUD functions on routers. However, many applications or implementations of tunneling / encapsulation protocols assume that the PMTUD would work. 6.2. Inappropriate AAAA replies Inappropriate DNS replies pointed in [RFC4074] are one of open issues on the IPv6 transitions. Ideally, vendors SHOULD implement web / DNS appliances with taking care of [RFC4074] and network operators SHOULD replace all AAAA resolvers to appropriate AAAA resolvers. However, such solution will spend money, human resources, and time to deployment. A possible immediate solution is changing the fallback routines of DNS64 resolvers as follows; o A DNS64 resolver resolves the A record even when a DNS reply contained NXDOMAIN or ServFail. o A DNS64 resolver caches all possible A records. When a DNS reply was NOERROR, the DNS64 resolver queries the AAAA record. If the AAAA record exists, then the DNS64 resolver returns the AAAA record to a client, and if not, the DNS64 resolver returns the cached A record to the client. These solutions would be required further discussion in appropriate working group. Hazeyama & Ueno Expires April 26, 2012 [Page 16] Internet-Draft Abbreviated Title October 2011 7. Conclusion and Future Work This experiment was the first time of WIDE Project on availability test of the IPv6 only connectivity with participants. Many participants replied good impressions, however, various issues were clarified through this experiment. We would like to store TIPS to operate the IPv6 only connectivity not only through the regular experiment on the WIDE camp, and also through the daily operation of the IPv6 only connectivity on the WIDE backbone. 8. Security Considerations As well as Arkko mentioned in [I-D.draft-arkko-ipv6-only-experience-03], the use of IPv6 instead of IPv4 by itself does not make a big security difference. In our experience, we only set up following security functions; the access control list on routers / servers, DNSSEC, accounting on the wireless network access. 9. IANA Considerations This document has no IANA implications. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. Hazeyama & Ueno Expires April 26, 2012 [Page 17] Internet-Draft Abbreviated Title October 2011 10.2. Informative References [I-D.draft-arkko-ipv6-only-experience] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", April 2011, . [I-D.draft-matsuhira-sa46t-applicability] Matsuhira, N., "Applicability of Stateless automatic IPv4 over IPv6 Tunneling (SA46T)", July 2011, . [I-D.draft-matsuhira-sa46t-as] Matsuhira, N., "Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing", April 2011, . [I-D.draft-matsuhira-sa46t-gaddr] Matsuhira, N., "Stateless Automatic IPv4 over IPv6 Tunneling: Global SA46T Address Format", July 2011, . [I-D.draft-matsuhira-sa46t-mcast] Matsuhira, N., "SA46T Multicast Support", September 2011, . [I-D.draft-matsuhira-sa46t-motivation] Matsuhira, N., "Motivation for developing Stateless Automatic IPv4 over IPv6 Tunneling (SA46T)", July 2011, . [I-D.draft-matsuhira-sa46t-spec] Matsuhira, N., "Stateless Automatic IPv4 over IPv6 Tunneling: Specification", July 2011, . [I-D.draft-murakami-softwire-4rd] Murakami, T., Troan, O., and S. Matsushima, "Stateless Automatic IPv4 over IPv6 Tunneling: Specification", September 2011, . [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", October 2010, . Hazeyama & Ueno Expires April 26, 2012 [Page 18] Internet-Draft Abbreviated Title October 2011 [I-D.ietf-behave-ftp64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", March 2011, . [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", August 2010, . [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", September 2010, . [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", July 2010, . [ISC-DHCP] Internet Systems Consortium., "DHCP", . [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [SEIL] Internet Initiative Japan, "SEIL", September 2011, . [YasudaAPRICOT2011] Yasuda, A., "Building for IPv6 by IPv6 Promotion Council Japan.", February, 2011, . [bind] Internet Systems Consortium., "BIND", . [linuxnat64] Geeknet, Inc., "Linux NAT64 implementation", . Hazeyama & Ueno Expires April 26, 2012 [Page 19] Internet-Draft Abbreviated Title October 2011 [vyatta-4RD] masakazu, "masakazu's weblog (In Japanese)", June 2011, . Appendix A. Acknowledgements Here, we thank to 153 participants of WIDE camp 2011 autumn on this experiments. We also say thank you to N. Matsuhira of Fujitsu for the SA46T implemnetation, H. Suenaga and K. Ooyatsu of IIJ for SEIL 4RD implementation, NTT EAST, Internet Multifeed, and IIJ for serving the commercial IPv6 Internet service for this experiment on the Matsushiro Royal Hotel. Authors' Addresses Hiroaki Hazeyama NAIST Takayama 8916-5 Nara, Japan Phone: +81 743 72 5216 Email: hiroa-ha@is.naist.jp Yukito Ueno Keio Univ. 5322 Endo Kanagawa, Japan Email: eden@sfc.wide.ad.jp Hazeyama & Ueno Expires April 26, 2012 [Page 20]