Network Working Group H. Hazeyama Internet-Draft NAIST Intended status: Informational R. Hiromi Expires: April 6, 2013 Intec Inc. T. Ishihara Univ. of Tokyo O. Nakamura WIDE Project October 3, 2012 Experiences from IPv6-Only Networks with Transition Technologies in the WIDE Camp Autumn 2012 draft-hazeyama-widecamp-ipv6-only-experience-02 Abstract This document reports and discusses issues on IPv6 only networks and IPv4/IPv6 transition technologies through our experiences on the 3rd experiment on the WIDE camp. The 3rd experiment was held from September 3rd to September 6th, 2012. As well as past two experiments, we conducted face to face interview to participants for grasping IPv6 capability on users' devices, OSes, and applications. In addition to this, we explored solutions to mitigate timeout / fallback problems of IPv4/IPv6 dual stack clients on an IPv6 only network that is composed of DHCP6 and DNS64/NAT64. 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 6, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Hazeyama, et al. Expires April 6, 2013 [Page 1] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hazeyama, et al. Expires April 6, 2013 [Page 2] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. History of ``Live with IPv6 experiments'' on the WIDE camp . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Summary of the 1st experiment . . . . . . . . . . . . 4 1.1.2. Summary of the 2nd experiment . . . . . . . . . . . . 4 1.2. Abstract of the 3rd experiment . . . . . . . . . . . . . . 6 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 7 3. Basic configuration of Network and Experiments . . . . . . . . 8 4. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. An Experiment in RA method . . . . . . . . . . . . . . . . 11 4.1.1. Details of Network Configuration . . . . . . . . . . . 11 4.1.2. User Survey . . . . . . . . . . . . . . . . . . . . . 12 4.1.2.1. Client Profile . . . . . . . . . . . . . . . . . . 12 4.1.2.2. Behaviors of DHCP6 Clients . . . . . . . . . . . . 13 4.1.2.3. Timeout / Fallback Problems . . . . . . . . . . . 14 4.2. Experiments in DHCP-PD method . . . . . . . . . . . . . . 14 4.2.1. Basic Network Configuration . . . . . . . . . . . . . 14 4.2.2. Experiment 0 . . . . . . . . . . . . . . . . . . . . . 15 4.2.2.1. Waiting timeout of DHCP4 in Windows 7 . . . . . . 16 4.2.2.2. Long TCP fallback in Mac OS X Lion and Mountain Lion . . . . . . . . . . . . . . . . . . 16 4.2.2.3. Incompletion of network settings in iOS 5 . . . . 16 4.2.2.4. Incapability of IPv6 DNS settings by DHCP6 . . . . 16 4.2.3. Experiment 1 . . . . . . . . . . . . . . . . . . . . . 17 4.2.3.1. Diff of network settings . . . . . . . . . . . . . 17 4.2.3.2. Result . . . . . . . . . . . . . . . . . . . . . . 18 4.2.4. Experiment 2 . . . . . . . . . . . . . . . . . . . . . 19 4.2.4.1. Diff of network settings . . . . . . . . . . . . . 19 4.2.4.2. Result . . . . . . . . . . . . . . . . . . . . . . 21 4.2.5. Experiment 3 . . . . . . . . . . . . . . . . . . . . . 21 4.2.5.1. Diff of network settings . . . . . . . . . . . . . 21 4.2.5.2. Result . . . . . . . . . . . . . . . . . . . . . . 22 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Hazeyama, et al. Expires April 6, 2013 [Page 3] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 1. Introduction This document reports and discusses issues on IPv6 only networks and IPv4/IPv6 transition technologies through our experiences on the 3rd experiment on the WIDE camp. The 3rd experiment was held from September 3rd to September 6th in Matsushiro Royal Hotel, Nagano, Japan, where is the same hotel of the 1st and 2nd experiments. 1.1. History of ``Live with IPv6 experiments'' on the WIDE camp "Live with IPv6 experiment" aims to evaluate commercial IPv6 network services, the availability of IPv6 networks with several IPv4 / IPv6 translation / encapsulation technologies by actual users' experiences, and to grasp issues on IPv4 exhaustion situation or IPv4 / IPv6 transition. These experiments are based on an assumption that ISP backbone networks will be constructed on IPv6 only and end customer will have to use an IPv6 network with 64 translators or an IPv4 network with 464 translators to keep current usage of the Internet services. 1.1.1. Summary of the 1st experiment The 1st experiment was held in Matsushiro Royal Hotel from September 6th to September 9th, 2011 with 153 participants, and the experiment result was reported in the v6ops BoF on IETF 82 Taipei. In the 1st experiment, we constructed an IPv6 only network with stateless NAT64 and DNS64 as a part of the WIDE backbone through IPv6 L2TP over a commercial IPv6 network service. The commercial IPv6 network service was provided by NTT-East as an Access Carrier, Internet MultiFeed (MFeed) as a Virtual Network Enabler (VNE) and IIJ as an IPv6 Internet Service Provider (IPv6 ISP). In addition to an IPv6 connectivity with NAT64/DNS64, we also tested a SA46T [I-D.draft-matsuhira-sa46t-spec] based IPv4 global network service and a murakami-4RD [I-D.draft-murakami-softwire-4rd] based IPv4 private network service (murakami-4RD is now merged into MAP [I-D.draft-ietf-softwire-map-02]). With referring IETF's IPv6 only network experiences [RFC6586], we reported several new issues on an IPv6 only network with IPv4 / IPv6 transition technologies, especially on inappropriate DNS replies mentioned in [RFC4074], on MTU mismatch, on VPN protocols and applications through IPv4 / IPv6 translators. 1.1.2. Summary of the 2nd experiment According to the experiences on the 1st experiment, the 2nd experiment was conducted from March 5th to March 8th, 2012 in Matsushiro Royal Hotel, the same hotel of the 1st experiment. 171 participants joined this 2nd experiment, most of them were engineers Hazeyama, et al. Expires April 6, 2013 [Page 4] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 or academic people. The 2nd experiment result was reported in the v6ops BoF on IETF 83 Paris. The settings of the core network in the 2nd experiment was same as the 1st experiment. In the 1st experiment, a commercial IPv6 network service was employed as a backbone network, in other word, we did evaluate the availability of commercial IPv6 network services from the view of home users. Therefore, the evaluation target of the 2nd experiment was planned as living in commercial IPv6 networks with IPv4 / IPv6 translation technologies or IPv4 / IPv6 translation services. The user access networks of the 2nd experiment were achieved by two types of commercial IPv6 network services through the NTT NGNv6 access network, with four kinds of IPv4 / IPv6 translation technologies. One of the two commercial IPv6 network services was /48 prefix IPv6 network service through IPoE[RFC0894] on NTT NGNv6 (we name it "native IPoE" in this draft), the other was /56 prefix IPv6 network service through PPPoE[RFC2516] on NTT NGNv6 (we label it "native PPPoE" in this draft) [YasudaAPRICOT2011]. Both IPv6 networks were served from NTT-East, MFeed and IIJ as same as the 1st experiment. Usually, IPv6 networks on both native IPoE and native PPPoE were provided with only DNS v6 proxy. We constructed DNS64/NAT64 service on the WIDE backbone and on the camp core network, and served it through stateless DHCP6 [RFC3736] both on native IPoE and on native PPPoE. Along with the DNS64/NAT64 translation service, for aiming to evaluate more practical approaches on the current commercial environments, we tested three IPv4 services over IPv6 networks, murakami-4RD [I-D.draft-murakami-softwire-4rd], SA46T [I-D.draft-matsuhira-sa46t-spec] and 464XLAT [I-D.draft-ietf-v6ops-464xlat]. We mainly served seven IP networks to participants by combination of those networks and translation services, that is, native IPoE with DNS64/NAT64, native PPPoE with DNS64/NAT64, murakami-4RD on both IPoE and PPPoE, 464XLAT on both IPoE and PPPoE, SA46T on PPPoE. Three evaluations were mainly conducted by the evaluation team, i) user survey about the availability of each network through face to face interview, ii) analysis of DNS behaviors to grasp inappropriate behaviors mentioned in [RFC4074], iii) availability test of VPN applications to analyze MTU problems For to grasp whether an unavailability of VPN applications was intentional one due to the specification of a translation technology or not. Also, Konami Digital Entertainment (KDE) joined in this experiment, and evaluated Hazeyama, et al. Expires April 6, 2013 [Page 5] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 NAT/Firewall traversal testing on each IPv6 network or each translator service from the view of commercial (P2P) Network Game services. KDE gave us the importance / requirements of hair-pinning functions and of MTU / packet fragmentation handling on NAT/NAPT for P2P based Multiplayer Online Games. 1.2. Abstract of the 3rd experiment The 3rd experiment was conducted from September 3rd to September 6th, 2012 in Matsushiro Royal Hotel, the same hotel of the past two experiments. 136 participants joined this 3rd experiment, most of them were engineers or academic people. The aims of 3rd experiments were 1) continuous user survey on IPv6 capability of devices, OSes and applications, 2) exploration of a practical solution to mitigate timeout / fallback problems of IPv4/ IPv6 dual stack clients on an IPv6 only network. The first aim was conducted to grasp the IPv6 capability of users' devices, OSes, and applications and to collect users' experiences through face to face interview. From the 2nd experiments, several new OSes or new devices have been released. Through this continuous survey, we saw the current development / deployment strategy of IPv6 on commercial vendors or Telecom / Internet Service providers. This user survey was mainly carried on September 3rd and September 4th. The second aim was derived from our experiences of an IPv6 only network with DHCP6/DNS64/NAT64 on past two experiments. In past two experiments, various OSes met several timeout / fallback problems, in the initial connection setting through Wi-Fi settings, in the name server selection, in the establishment of a TCP connection. Most OSes and applications, that met tedious timeout / fallback problems, preferred IPv4 to IPv6, or required IPv4 settings to enable IPv6 settings. These timeout / fallback problems were seemed to be derived from an assumption that there are no IPv6 only network on the current situation. Toward the sunset of IPv4, we have to explore and achieve a practical solution to move from IPv4/IPv6 dual stack networks to IPv6 only networks without giving stress or difficulties to end users. In IPv4/IPv6 transition situation, end users will usually use IPv4/IPv6 dual stack mode, and they will leave all IPv4 / IPv6 network settings by OSes' auto configuration behaviors on their devices except for selecting Wi-Fi connections. We focused on testing an IPv6 only network that was basically composed of DHCP6, DNS64 and NAT64. In this IPv6 only network, we sought a current practice of timeout / fallback mitigation among Hazeyama, et al. Expires April 6, 2013 [Page 6] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 IPv4/IPv6 dual stack networks and IPv6 only networks. According to results of the user survey, we added several functions to a basic DHCP6/DNS64/NAT64 network in step by step fashion, and we analyzed or revised mitigation methods for timeout / fallback problems. This draft is composed of following sections. We explain the overview of the network settings in the 3rd experiment at first. Next, we report the result of the user survey. Then, we describe the experiment on timeout / fallback mitigation methods. Finally, we summarize our practical timeout / fallback mitigation method. We also mention about limitations our mitigation method and our recommendations on development / deployment of IPv6 capability on end clients. 1.3. 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], [RFC6144], [RFC6145], [RFC6146], [RFC6384]. "DNS64" refers DNS extensions to use NAT64 translation from IPv6 clients to IPv4 servers with name resolution mechanisms that is defined in [RFC6147]. "DHCP4" refers Dynamic Host Configuration Protocol for IPv4 that is defined in [RFC2131]. "DHCP6" refers Dynamic Host Configuration Protocol for IPv6. So called "Stateful DHCP6" is defined in [RFC3315] and "Stateless DHCP6" is defined in [RFC3736]. "DHCP-PD" or "DHCPv6 Prefix Delegation" refers IPv6 Prefix Options for DHCP6 that is initially defined in [RFC3633] and updated in [RFC6603]. Hazeyama, et al. Expires April 6, 2013 [Page 7] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 "ND" refers Neighbor Discovery for IP version 6 (IPv6) that is defined in [RFC4861] and updated in [RFC5942]. 3. Basic configuration of Network and Experiments The WIDE Camp Autumn 2012 was held at Matsushiro Royal Hotel in Nagano Prefecture of Japan, the same place of the 1st and 2nd experiment, from September 3rd to September 6th, 2012. Figure 1 shows the overview of the whole network topology on the WIDE Camp Autumn 2012. Besides our IPv6 only experiments, the camp NOC team set up a core network (camp-net-core) for preparing a backup plan of our IPv6 only network experiments and for conducting other experiments such as OLSR emulation, SA46T-AT [I-D.draft-matsuhira-sa46t-at-00] and NAT44 double translation, and measurement of a satellite link. All server instances and routing instances of the core network were built on StarBED that is a cloud / network emulation testbed in Japan. We constructed two layer 2 tunnels between StarBED and Matsushiro Royal hotel through IPv4 PPPoE. The layer 2 tunnels over IPv4 PPPoE were constructed by NEC IX2015. The OLSR network and the satellite link were served as IPv4 / IPv6 dual stack networks. The wireless Accesses to these networks were provided by CISCO Systems Mesh Wi-Fi Access Point and WLC (Wireless LAN Controller). As well as our 2nd experiment, a commercial IPv6 service was employed to achieve our IPv6 only network experiments. The Access Carrier (AC), the Virtual Network Enabler (VNE) and the IPv6 Internet Service Provider (v6ISP) of this 3rd experiment were same combination of past experiments, that is, NTT-East as AC, MFeed as the VNE and IIJ Mio as v6ISP. We contracted two external FTTH lines by NTT NGNv6 IPoE method. We changed the IPv6 address allocation method on NTT NGNv6 IPoE during this camp. From September 2th (the preparation day) to September 4th, we used the RA method for the external connectivity. Figure 2 represents details of the IPv6 only network by RA method. From September 5th to September 6th, we changed the external connectivity to the DHCP-PD method. In the RA method, we tested the DHCP6 client behaviors when two stateless DHCP6 servers exist, one is placed by the VNE or ISP to indicate AAAA name servers, the other is located in the local subnet to lead clients to a DNS64 name server. On the other hand, we explored mitigation methods for timeout / fallback problems after we changed the external connectivity to the DHCP-PD method. We explain the experiment on the RA method in Section 4.1 and the experiments on Hazeyama, et al. Expires April 6, 2013 [Page 8] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 the DHCP-PD method in Section 4.2, respectively. We employed following implementations for key components; o DNS64 and recursive cache server: NLNet Labs Unbound 1.4.7 with DNS64 patch o NAT64 : OpenBSD 5.1 PF (Packet Filter) o DHCP-PD client : WIDE DHCP client (dhcp6c) o Stateless DHCP6 server : Alaxala 3630 Hazeyama, et al. Expires April 6, 2013 [Page 9] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 +----------------------------------------------------+ | The Internet (IPv4 / IPv6) | +----------------------------------------------------+ | | | | | | +-----------+ | +--------------+ | IIJ (ISP) | | | WIDE (ISP) |---------+ +-----------+ | +--------------+ | | | | | | | | | (L2 Tunnel) | | | (IPv4/IPv6) | | | | | +---------+ | | | | | IX 2015 | | +-----------+ | +---------+ | |MFeed (VNE)| | | | +-----------+ +---------------+ +-------------+ | | camp-net-core | | SAT station | | +---------------+ +-------------+ | | +--------------------------+ | | NTT NGNv6 (Access Line) | (satellite link) +--------------------------+ | | | +-------------+ (IPoE method) | SAT station | | | +-------------+ | +--------------+ | | | | | (native IPv6) (L2 tunnel over IPv4 PPPoE) (L2 Tunnel) | | | | | | +---------+ +---------+ | | | IX 2015 | | IX 2015 | | | +---------+ +---------+ | | | | | | (vlan) (vlan) | | | | +------------------------------------------------------------+ | Wi-fi Access (CISCO Layer 2 mesh, 11b/g/n Wi-fi) | +------------------------------------------------------------+ Over view of the 2nd experiment topology Figure 1 Hazeyama, et al. Expires April 6, 2013 [Page 10] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 4. Experiments 4.1. An Experiment in RA method 4.1.1. Details of Network Configuration The experiment conducted in RA method was overwriting client DNS information by a local stateless DHCP6 server. Figure 2 shows the test network topology. The RA method provided /64 prefix addresses and routing information through RA. The RA was set managed flag as zero (M flag == 0) and the other flag to one (O flag == 1) to let clients query to stateless DHCP6 servers. In this case, a stateless DHCP6 server was placed on the VNE network of MFeed and IIJ that advertised two AAAA name servers. Those two AAAA name servers returned only AAAA records to any queries. We wanted to inform only the DNS64 IPv6 address to clients on this RA method while using address assignment and default route settings by the RA method. Of course, we could not control the DHCP6 server on the VNE network. Therefore, we tried to use the preference option of DHCP6. The preference option of DHCP6 (section 22.8 of [RFC3315]) defines that "the Preference option is sent by a server to a client to affect the selection of a server by the client". Section 17.1.3 of [RFC3315] defines the criteria on the behavior of DHCP6 server selection by a client when the client has received two or more valid advertise messages; o Those Advertise messages with the highest server preference value are preferred over all other Advertise messages. o Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, the client may choose a server that returned an advertisement with configuration options of interest to the client. o The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. We assumed we could overwrite the name server information by sending advertise messages with highest preference value from a local stateless DHCP6 server. Thus, we placed a local stateless DHCP6 server shown in Figure 2. Hazeyama, et al. Expires April 6, 2013 [Page 11] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 This overwriting was partially succeeded as well as we assumed, however, several inconveniences were reported through face to face interview and inspection by the special observation team. +-------+ +------+ | DNS64 | | NAT64| +-------+ +------+ | | (-- StarBED --) | | +--------------- IPv6 Internet ----------------------+ | +-------------+ | IPv6 router | | on ISP | +-------------+ | +---------+ +---------+ +----------+ +---------+ | IPv6 GW | | DHCP6 | |AAAA name | | DHCP6 | | | | to AAAA | | servers | | to DNS64| +---------+ +---------+ +----------+ +---------+ | | | | (---------- VNE --------------) (-- Hotel --) | | | | +---------------- /64 prefix segment -----------------------+ | +---------------+ | users devices | +---------------+ The Test Topology on RA method Figure 2 4.1.2. User Survey 59 participants (42.8 %) replied our face to face interview. We show the client profile in Section 4.1.2.1 and reported troubles in Section 4.1.2.2 and Section 4.1.2.3. 4.1.2.1. Client Profile 94 unique devices were profiled. The distribution of the pair of device and OS were shown in Table 1. Hazeyama, et al. Expires April 6, 2013 [Page 12] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 +-------------------+----------------------+-------------------+ | Device Type | OS Type | # of devices (%) | +-------------------+----------------------+-------------------+ | PC/AT Note PC | Windows 7 | 16 (17.0 %) | | ----------------- | ----------------- | ----------------- | | PC/AT Note PC | NetBSD | 2 (2.1 %) | | ----------------- | ----------------- | ----------------- | | PC/AT Note PC | Linux | 4 (4.3 %) | | ----------------- | ----------------- | ----------------- | | Apple Note PC | Mountain Lion | 15 (16.0 %) | | ----------------- | ----------------- | ----------------- | | Apple Note PC | Lion | 18 (19.1%) | | ----------------- | ----------------- | ----------------- | | Apple Note PC | Snow Leopard | 9 (9.6 %) | | ----------------- | ----------------- | ----------------- | | Apple Note PC | Windows 7 (Bootcamp) | 3 (3.2 %) | | ----------------- | ----------------- | ----------------- | | iPhone / iPod | iOS 5 | 9 (9.6 %) | | ----------------- | ----------------- | ----------------- | | Android Phone | Android OS 4 | 3 (3.2 %) | | ----------------- | ----------------- | ----------------- | | Android Phone | Android OS 2 | 4 (4.3 %) | | ----------------- | ----------------- | ----------------- | | Android Phone | Android OS 1 | 1 (1.0 %) | | ----------------- | ----------------- | ----------------- | | iPad | iOS 6 | 1 (1.0 %) | | ----------------- | ----------------- | ----------------- | | iPad | iOS 5 | 6 (6.4 %) | | ----------------- | ----------------- | ----------------- | | Android Tablet | Android OS 4 | 2 (2.1 %) | | ----------------- | ----------------- | ----------------- | | Kindle | Kindle 3.3 | 1 (1.0 %) | | ----------------- | ----------------- | ----------------- | | Total | | 94 | +-------------------+----------------------+-------------------+ Table 1: The distributions of devices of participants 4.1.2.2. Behaviors of DHCP6 Clients Many users reported inconveniences of DHCP6 client behaviors in the RA method. We focused on the analysis of DHCP6 client behavior of Windows 7 and of Mac OS X Lion / Mountain Lion. Both Windows 7 and Mac OS X usually stored DNS64 IPv6 address to their name server information, however, both of them sometime stored two AAAA name servers on the VNE network. Differences of their DHCP6 client behaviors were as follows; Hazeyama, et al. Expires April 6, 2013 [Page 13] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 o In most cases, Windows 7 preferred to the advertise message from the local DHCP6 server that indicated the DNS64 server, however, it often preferred the advertise message from the DHCP6 server on the VNE network at the RA refresh timing. * When the DHCP6 client preferred to the DHCP6 server on the VNE network, an user had to reset the Wi-Fi device of his/her PC and to reconnect to the Wi-Fi network. "ipconfig /renew" or simply reconnecting by Wi-Fi selection icon often failed to prefer the advertise message from the local DHCP6 server. o On the other hand, Mac OS X Lion and Mountain Lion often failed to prefer the advertise message from the local DHCP6 server at the initial set up on Wi-Fi setting, however, "Renew DHCP lease" on the detail of network settings always preferred to the advertise message from the local DHCP6 server, that is, Mac OS X always changed the name server setting to only DNS64 IPv6 address by "Renew DHCP lease". At RA refresh timing, Mac OS X sometime preferred to the DHCP6 server on the VNE network, then, the user had to refresh DHCP configurations again. 4.1.2.3. Timeout / Fallback Problems Many users reported inconveniences due to timeout / fallback problems. Root causes were roughly categorized into 1) troubles of DNS64, 2) incapability of IPv6 and of DNS64 on various servers and applications mentioned in [RFC4074] and [RFC6586], 3) incapability of DHCP6 client and / or IPv4 dependency on OSes. In Section 4.2, we explain the detail of timeout / fallback problems without effects by the selection of stateless DHCP6 servers. 4.2. Experiments in DHCP-PD method On the contrary of the RA method mentioned in Section 4.1, the DHCP-PD method provided /56 prefix delegation by DHCP6 prefix delegation mechanism. We settled a DHCP-PD client PC router and set up static routes to two delegated /64 networks, one was labeled as "v6only-basic", the other was named as "v6only-fallback". The v6only-basic network was a basic IPv6 only network that was composed of stateless DHCP6, DNS64 and NAT64. On the other hand, we tested several timeout / fallback mitigation methods in "v6only-fallback". Figure 3 shows the basic network topology of experiments on DHCP-PD method. 4.2.1. Basic Network Configuration Figure 3 shows the basic network topology of experiments on DHCP-PD method. Hazeyama, et al. Expires April 6, 2013 [Page 14] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 +-------+ +------+ | DNS64 | | NAT64| +-------+ +------+ | | (-- StarBED --) | | +--------------- IPv6 Internet ----------------------+ | +-------------+ +----------------+ | IPv6 router | | DHCP PD server | | on ISP | | on VNE | +-------------+ +----------------+ | | +-- (VNE network) ----------------+----------------------+ | |(v6) | (---- Hotel ----) | +---------------+ | DHCP-PD Client| | PC router | +---------------+ | +-----------------+ | | Stateless DHCP6 | | +-----------------+ | | | | | +------------- each /64 prefix segment ---------------+ | +---------------+ | users devices | +---------------+ Basic Network Topology on DHCP-PD method (v6only-basic) Figure 3 4.2.2. Experiment 0 In the experiment 0, we observed OSes behaviors again. Actually, the inconvenience on the selection of two stateless DHCP6 servers were resolved by DHCP-PD and placing one stateless DHCP6 server onto each /64 prefix subnet. However, we clearly recognized several timeout / fallback problems. In following sections, we explain timeout / fallback problems due to DHCP6 client incapability and IPv4 Hazeyama, et al. Expires April 6, 2013 [Page 15] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 dependency of OSes. 4.2.2.1. Waiting timeout of DHCP4 in Windows 7 In Windows 7, timeout of DHCP4 queries spent a few minutes in the initial Wi-Fi connection setup. After fallback on the initial Wi-Fi connection, there were no problem on using IPv6 capable applications. DNS64 fallback failures due to the inappropriate authoritative servers still occurred, however, several authoritative servers, that returned inappropriate AAAA reply in past experiments, had been fixed to have appropriate fallback. 4.2.2.2. Long TCP fallback in Mac OS X Lion and Mountain Lion Mac OS X implementations, such as Lion and Mountain Lion, had more serious timeout / fallback problems than Windows 7. After the timeout of DHCP4 queries with a few minutes as well as Windows 7, the interface that is allocated IPv4 link local address was inserted as IPv4 default route. This Mac OS X behavior may be along with IPv4 on-link assumption in Section 3.3 of [RFC3927]. Section 3.3 of RFC3927 mentions "Interaction with Hosts with Routable Addresses", which assumes all IPv4 address are on-link at Link-Local configuration. Also, getaddrinfo implementation on Mac OS X did HappyEyeball like behavior. The getaddrinfo of Mac OS X returned an IP address list where IPv4 addresses were inserted the top of the list initially. Combining the on-link-assumption and the HappyEyeball like getaddrinfo caused long long TCP fallback from IPv4 to IPv6 in the initial TCP connection setup. Once the long long TCP fallback occurred, getaddrinfo of Mac OS X marked some flag that IPv4 is not available at the moment, then the getaddrinfo gave higher priority to IPv6 addresses than IPv4 addresses until ARP and / or ND tables were refreshed. When ARP and / or ND tables were refreshed, Mac OS X users face long long TCP fallback from IPv4 to IPv6 again. 4.2.2.3. Incompletion of network settings in iOS 5 In iOS 5, "Network Setting" were not completed, "Network Settings" will be completed only if IPv4 address, IPv4 router, and IPv4 DNS can be retrieved via DHCPv4 or manually configured all of these 3. 4.2.2.4. Incapability of IPv6 DNS settings by DHCP6 Windows XP, older Mac OS X (Snow Leopard and older) and Android OS required an IPv4 address for an DNS server even when they can use IPv6. In an IPv6 only network, DNS information should be gotten via DHCP6, these OSes did not support DHCP6 client. Also, Android cannot Hazeyama, et al. Expires April 6, 2013 [Page 16] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 be configured to use DNS over IPv6 even in manual configuration. 4.2.3. Experiment 1 4.2.3.1. Diff of network settings In the Experiment 1, we added a DHCP4 server that provided only IPv4 private address to DHCP4 client without the default gateway IPv4 address nor IPv4 address of DNS. We employed ISC-DHCP for this DHCP4 server. Hazeyama, et al. Expires April 6, 2013 [Page 17] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 +-------+ +------+ | DNS64 | | NAT64| +-------+ +------+ | | (-- StarBED --) | | +--------------- IPv6 Internet ----------------------+ | +-------------+ +----------------+ | IPv6 router | | DHCP PD server | | on ISP | | on VNE | +-------------+ +----------------+ | | +-- (VNE network) ----------------+----------------------+ | |(v6) | (---- Hotel ----) | +---------------+ | DHCP-PD Client| | PC router / | | DHCP4 | +---------------+ | +-----------------+ | | Stateless DHCP6 | | +-----------------+ | | | | | +------------- /64 prefix segment ---------------+ | +---------------+ | users devices | +---------------+ Test Topology on Experiment 1 (v6only-fallback) Figure 4 4.2.3.2. Result As the result of Experiment 1, only timeout of DHCP4 was solved, that is, only Windows 7 was working well without any fallback problems except for DNS64 name resolving. TCP fallback problem on MacOS X still occurred. iOS applications were sometimes working, but periodically failed due to retrying Wi-Fi connection setup. Hazeyama, et al. Expires April 6, 2013 [Page 18] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 4.2.4. Experiment 2 4.2.4.1. Diff of network settings In the Experiment 2, we put BIND9 forwarder on-link and configured DHCP4/6 to use this DNS. We configured BIND9 forwarder with: * deny- answer-addresses { 0.0.0.0/0; }; * which directed that no IPv4 address answer should be trusted. It returned SERVFAIL to resolvers. Hazeyama, et al. Expires April 6, 2013 [Page 19] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 +-------+ +------+ | DNS64 | | NAT64| +-------+ +------+ | | (-- StarBED --) | | +--------------- IPv6 Internet ----------------------+ | +-------------+ +----------------+ | IPv6 router | | DHCP PD server | | on ISP | | on VNE | +-------------+ +----------------+ | | +-- (VNE network) ----------------+----------------------+ | |(v6) | (---- Hotel ----) | +------------------+ | DHCP-PD Client | | PC router / | | DHCP4 / | | Bind 9 forwarder | | which treats "A" | | as SERVAFAIL | +------------------+ | +-----------------+ | | Stateless DHCP6 | | +-----------------+ | | | | | +------------- /64 prefix segment ---------------+ | +---------------+ | users devices | +---------------+ Test Topology on Experiment 2 (v6only-fallback) Figure 5 Hazeyama, et al. Expires April 6, 2013 [Page 20] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 4.2.4.2. Result As result of Experiment 2, Android was working well. iOS was working, but periodically failed due to retrying to Wi-Fi connection setup. MacOS X variants were working, but timeout by TCP fallback still occurred. Windows XP was not working because all DNS queries failed due to SERVFAIL. 4.2.5. Experiment 3 4.2.5.1. Diff of network settings In the Experiment 3, we hacked AAAA filtering code on BIND9 to filter "A records" instead of "AAAA records" both on IPv4/IPv6 transport. We put BIND9 above to the local link, which was configured to forward all queries to DNS64. We also configured DHCP4/DHCP6 to use the DNS proxy. Hazeyama, et al. Expires April 6, 2013 [Page 21] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 +-------+ +------+ | DNS64 | | NAT64| +-------+ +------+ | | (-- StarBED --) | | +--------------- IPv6 Internet ----------------------+ | +-------------+ +----------------+ | IPv6 router | | DHCP PD server | | on ISP | | on VNE | +-------------+ +----------------+ | | +-- (VNE network) ----------------+----------------------+ | |(v6) | (---- Hotel ----) | +-------------------+ | DHCP-PD Client | | PC router / | | DHCP4 / | | Bind 9 DNS Proxy | | with "A" filter | +-------------------+ | +-----------------+ | | Stateless DHCP6 | | +-----------------+ | | | | | +------------- /64 prefix segment ---------------+ | +---------------+ | users devices | +---------------+ Test Topology on Experiment 3 (v6only-fallback) Figure 6 4.2.5.2. Result As the result of Experiment 3, Windows XP, MacOS X variants, iOS, Android were working well. Some of applications still failed on IPv6 only due to the IPv6 incapability or DNS64 fallback problem, but many Hazeyama, et al. Expires April 6, 2013 [Page 22] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 cases were fine: IE/Safari/Chrome/Firefox, Twitter, Facebook, Instagram, and so on. Remaining issues were connection failures during a few minutes after Wi-Fi was connected. We guess the possible reason of this failures as follows: RS (Router Solicitation) was sent from kernel before Wi-Fi link was established. No IPv6 address was obtained until periodical RA (Router Advertisement) was received. The possible workaround to this connection failure is shortening RA interval to 5-10 seconds (though it disturb Wi-Fi ...) or detecting association through AP log and kicking RS or RA. 5. Conclusion Timeout / fallback problems on IPv4/IPv6 dual stack clients in an IPv6 only network are caused by 1. timeout and fallback sequence on DHCP4 queries, 2. timeout and fallback sequence on the connectivity check to the IPv4 internet after the DHCP4 auto configuration, 3. connection retry sequence when the connectivity to the IPv4 internet was not given. 4. timeout and fallback sequence of a TCP connection on Mac OS X variants due to their HappyEyeball like behavior of getaddrinfo, 5. preference / dependency of IPv4 on name resolution, 6. connection failures during 1-2 minutes after Wi-Fi was connected. To mitigate these timeout / fallback problems, our current practice is composed of following components; o Configure a DNS64 and a NAT64 in somewhere. o Configure a Dual-stack DNS proxy as follows * The DNS proxy forwards all queries to the DNS64 except "A" query type (IPv4 address). Since there is no IPv4 connectivity on the client, all queries to "A" should be filtered and the DNS proxy returns NO DATA, just like "AAAA" filtering. * This "A" filter should be enabled both on IPv4 and IPv6 transport. Hazeyama, et al. Expires April 6, 2013 [Page 23] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 * This Dual-stack "A" filter DNS proxy should be "on-link" and reachable from IPv4/IPv6 dual stack mode clients. o Configure a DHCP4 server to reply a private IPv4 address, an IPv4 gateway router, and IPv4 address of an "A" filter DNS proxy to DHCP4 client. o Configure a DHCP6 server to indicate the IPv6 address of "A" filter DNS Proxy to DHCP6 client. * The IPv6 address of "A" filter DNS Proxy may be provided to IPv4/IPv6 dual stack mode clients by RDNSS [RFC6106]. However, from our experience on hot stage of Camp 1209 Autumn, Mac OS X Lion and Mountain Lion could handle RDNSS, but Windows 7 did not handle RDNSS. * Only one DHCP6 server should be placed in each /64 prefix segment or indicated by DHCP6 relay. According to our experience, we do not recommend overwriting DNS information by a local stateless DHCP6 server with highest preference value due to the differences of handling multiple DHCP6 replies among DHCP6 client implementations. o Configure the IPv4 gateway router not to forward any IPv4 packets. 6. Security Considerations As well as Arkko mentioned in [RFC6586], 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, accounting on the wireless network access. 7. IANA Considerations This document has no IANA implications. 8. References 8.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 Hazeyama, et al. Expires April 6, 2013 [Page 24] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 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. 8.2. Informative References [I-D.draft-ietf-softwire-map-02] Troan, O., Bao, C., Matsushima, S., and T. Murakami, "Mapping of Address and Port with Encapsulation (MAP)", September 5, 2012, . [I-D.draft-ietf-v6ops-464xlat] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", September 2012, . [I-D.draft-matsuhira-sa46t-at-00] Matsuhira, N., Horiba, K., Ueno, Y., and O. Nakamura, "SA46T Address Translator", July 2011, . [I-D.draft-matsuhira-sa46t-spec] Matsuhira, N., "Stateless Automatic IPv4 over IPv6 Tunneling: Specification", July 2012, . [I-D.draft-murakami-softwire-4rd] Murakami, T., Troan, O., and S. Matsushima, "Stateless Automatic IPv4 over IPv6 Tunneling: Specification", September 2011, . [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999. Hazeyama, et al. Expires April 6, 2013 [Page 25] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, July 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. Hazeyama, et al. Expires April 6, 2013 [Page 26] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012. [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012. [YasudaAPRICOT2011] Yasuda, A., "Building for IPv6 by IPv6 Promotion Council Japan.", February, 2011, . Appendix A. Acknowledgments Here, we thank to all the participants of WIDE camp on the experiments. We also say thank you to whom serving implementations and services in the Matsushiro Royal Hotel. R. Nakamura of Univ. of Tokyo, Y. Ueno of Keio Univ. and R. Shouhara of Univ. of Tokyo for helping us on the base settings of the IPv6 only experiments and merging into the camp-net. O. Onoe of Sony Corporation for his deep inspection and testing of end node devices. T. Jimei of Internet Systems Consortium for his quick hack on A filter of Bind 9. Y. Atarashi of Alaxala Networks and R. Atarashi of IIJ Innovation Institute for designing the items of face to face interview and analyzing user survey data. Authors' Addresses Hiroaki Hazeyama NAIST Takayama 8916-5 Nara, Japan Phone: +81 743 72 5216 Email: hiroa-ha@is.naist.jp Hazeyama, et al. Expires April 6, 2013 [Page 27] Internet-Draft IPv6 Experiments in the WIDE Camp October 2012 Ruri Hiromi Intec Inc. 1-3-3 Shin-Suna, Koutou Tokyo, Japan Email: hiromi@inetcore.com Tomohiro Ishihara Univ. of Tokyo 3-8-1 Komaba, Meguro Tokyo, Japan Email: sho@c.u-tokyo.ac.jp Osamu Nakamura WIDE Project 5322 Endo Kanagawa, Japan Email: osamu@wide.ad.jp Hazeyama, et al. Expires April 6, 2013 [Page 28]