Network Working Group H. Hazeyama Internet-Draft NAIST Intended status: Informational R. Hiromi Expires: September 14, 2012 Intec Inc. T. Ishihara Univ. of Tokyo O. Nakamura WIDE Project March 13, 2012 Experiences from IPv6-Only Networks with Transition Technologies in the WIDE Camp Spring 2012 draft-hazeyama-widecamp-ipv6-only-experience-01 Abstract This document reports and discusses issues on IPv6 only networks and IPv4/IPv6 transition technologies through our experiences on the 2nd experiment on the WIDE camp. The second experiment was held from March 4th to March 8th, 2012. We tried to live in commercial IPv6 networks with four kinds of IPv4/IPv6 transition technologies, DNS64/ NAT64, 4RD, 464XLAT and SA46T. In this -01.txt aims to report results of the 2nd experiment and to share issues / problems on the IPv4 / IPv6 transition that we met. 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 September 14, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Hazeyama, et al. Expires September 14, 2012 [Page 1] Internet-Draft IPv6 Experiments in the WIDE Camp March 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 September 14, 2012 [Page 2] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. History of ``Live with IPv6 experiment'' on the WIDE camp . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.1. Summary of the 1st experiment . . . . . . . . . . . . 5 1.1.2. Abstract of the 2nd experiment . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 7 3. Network and Experiment Setup . . . . . . . . . . . . . . . . . 7 3.1. IPv6 networks . . . . . . . . . . . . . . . . . . . . . . 10 3.2. IPv4 networks . . . . . . . . . . . . . . . . . . . . . . 11 3.3. DNS Settings . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. NAT64 Settings . . . . . . . . . . . . . . . . . . . . . . 13 3.5. Wireless networks . . . . . . . . . . . . . . . . . . . . 13 3.6. Settings for MTU and NAT / Firewall Traversal Tests for commercial (P2P) Network Games . . . . . . . . . . . . 15 4. Experiences from the Experiments . . . . . . . . . . . . . . . 15 4.1. User Survey by face-to-face interview . . . . . . . . . . 15 4.1.1. Client Profile . . . . . . . . . . . . . . . . . . . . 15 4.1.2. Reported Troubles . . . . . . . . . . . . . . . . . . 17 4.1.2.1. Failure of IPv6 neighbor discovery due to the on-link assumption of IPv4 network . . . . . . . . 17 4.1.2.2. Locked out IPv6 by vendor . . . . . . . . . . . . 18 4.1.2.3. Inappropriate selection of DNS resolvers . . . . . 18 4.1.2.4. Previous configuration lived after moving to another WiFi network . . . . . . . . . . . . . . . 18 4.1.2.5. Crash of an application by plug-in . . . . . . . . 18 4.1.2.6. Happy Eyeball implementation with turn-on/off switch . . . . . . . . . . . . . . . . . . . . . . 19 4.1.2.7. Different behavior among OSes on MTU handling . . 19 4.2. MTU and NAT Traversal Tests for Network Games . . . . . . 20 4.2.1. Between a Client and the STUN Server . . . . . . . . . 20 4.2.2. Between Clients with NAT . . . . . . . . . . . . . . . 24 4.3. Analysis of inappropriate authoritative servers from DNS64 Log . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Dependency between IPv4 and IPv6 address configuration . . 26 5.2. PMTUD, MTU mismatch problems and NAT behavior problems . . 27 5.3. Workaround for DNS64 problems . . . . . . . . . . . . . . 27 5.3.1. Workaround for illegal NameError . . . . . . . . . . . 27 5.3.2. Workdaround for lame delegation . . . . . . . . . . . 27 6. Conclusion and Future Work . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 Hazeyama, et al. Expires September 14, 2012 [Page 3] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Hazeyama, et al. Expires September 14, 2012 [Page 4] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 1. Introduction This document reports and discusses issues on IPv6 only networks and IPv4/IPv6 transition technologies through our experiences on the 2nd experiment on the WIDE camp. The 2nd experiment was held from March 5th to March 8th in Matsushiro Royal Hotel, Nagano, Japan, where is the same hotel of the 1st experiment. 1.1. History of ``Live with IPv6 experiment'' 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. This experiment is 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 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 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 based IPv4 global network service and a 4RD based IPv4 private network service. With referring IETF's IPv6 only network experiences [I-D.draft-arkko-ipv6-only-experience], 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. Abstract 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 or academic people. 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, Hazeyama, et al. Expires September 14, 2012 [Page 5] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 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, Internet MultiFeed 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 DHCP6[RFC3736][RFC6106] 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, 4RD, SA46T and 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, 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 or 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 NAT/Firewall traversal testing on each IPv6 network or each translator service from the view of commercial (P2P) Network Game services. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Hazeyama, et al. Expires September 14, 2012 [Page 6] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 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], [RFC6147], [RFC6384]. "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 defined in [I-D.draft-murakami-softwire-4rd]. "464XLAT" refers to Combination of Stateful and Stateless Translation defined in [I-D.draft-ietf-v6ops-464xlat]. 3. Network and Experiment Setup The WIDE camp spring 2012 was held at Matsushiro Royal Hotel in Nagano Prefecture of Japan, the same place of the 1st experiment, from March 5th to March 8th, 2012. Figure Figure 1 shows the overview of the test topology on the 2nd experiment, and Figure Figure 2 and Figure Figure 3 represent details of the network in Matsushiro Royal Hotel. We, WIDE Project, set up the same IPv6 only network of the 1st experiment held in September 2011 as a core network, dual stack and SA46T on PPPoE through IPv6 L2TP tunnel with using WIDE backbone's address blocks. Together with these core network settings by WIDE Project, we added actual use cases of commercial IPv6 networks and translation services with supports from a Japanese Access Carrier (NTT-East), an ISP (IIJ), an IX (JPIX), a VNE (Internet MultiFeed), a Hazeyama, et al. Expires September 14, 2012 [Page 7] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 network equipment vendor (NEC AccessTechnica) and a SIer (NTT Advanced Technology). +-----------------------------------------------+ | The Internet | +-----------------------------------------------+ | | | | +------+ | | | | | PLAT | | | | | +------+ | | | | | | | | | +------+ | | | | | JPIX |--+ | | | +------+ | | | | | | +-----------+ | +------------+ | IIJ (ISP) | | | WIDE (ISP) | +-----------+ | +------------+ | | | | | +------+ +-----------+ | +-------+ |4RD-BR| |MFeed (VNE)| +-------+ | SA46T | +------+ +-----------+ |v6 L2TP| +-------+ | +-------+ +--------------------------------+ | NTT NGNv6 (Access Line) | +--------------------------------+ | +------------------------------------------------------------+ | IPv6 test networks | |+-PD Router-+ +---4RD-CE---+ +----CLAT----+ +---- L2TP ----+| || IPv6 only | | 4RD | | 464XLAT | | SA46T | dual || ||-----------| |------------| |------------| |--------------|| ||IPoE |PPPoE| |IPoE | PPPoE| |IPoE | PPPoE| | PPPoE || |+-----------+ +------------+ +------------+ +--------------+| +------------------------------------------------------------+ | +------------------------------------------------------------+ | 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 September 14, 2012 [Page 8] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +----------------+ | NTT NGNv6 | +----------------+ |(NGN IPoE Access Service) +--------+ | ONU-48 | 2409:150:8000::/48 +--------+ | +--Flets IPv6 -------------+-----------------------------+ | |(v6) +-------------+ +---------------| PD Router |-------------+ | +-------------+ | | |(v6) | | +-------+ +--------+ +--------+ | | DHCP6 | | CLAT | | 4RD-CE | | +-------+ +--------+ +--------+ | | | | | | | | | | | | +- global v6 -+ +- global v6 -+ +- private v4-+ no ipv4 private v4 no v6 with with with NAT64/DNS64 DNS v4/ v6 Proxy DNSv4 proxy on the camp of CLAT of 4RD-CE The Test Topology on NTT NGNv6 IPoE service Figure 2 Hazeyama, et al. Expires September 14, 2012 [Page 9] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +-------------------+ | IIJ PPPoE Service | +-------------------+ | (NGN PPPoE Access Service) +--------+ | ONU-56 | +--------+ | +--IIJ PPPoE IPv6 -----+---------------- 2001:240:2002:6d00::/56 |(v6) +-------------+ (v6) +---------+ | PPPoE Client|------------------| v6 L2TP | +------------| & PD router |---------+ +---------+ | +-------------+ | | |(v6) |(v6) |(v6) |(dual) | +-------+ +--------+ +--------+ +--------+ | | DHCP6 | | CLAT | | 4RD-CE | | router |---+ | +-------+ +--------+ +--------+ +--------+ | | | |(dual) |(v4) | +-dual stack-+ | | | | | (WIDE) | | | | | +-------+ | | | | | | SA46T | +- global v6 -+ +- global v6 -+ +- private v4-+ | +-------+ no v4 private v4 no v6 | | with with with | | +-----+ DNS64/NAT64 DNS v4/v6Proxy DNS v4 Proxy | | |DHCP4| on the camp of CLAT of 4RD-CE | | +-----+ | | | +-- global v4 --+ no v6 with DNS4 on the camp The Test Topology on NTT NGNv6 PPPoE service Figure 3 3.1. IPv6 networks The same IPv6 network of the 1st experiment was achieved as a core network in the 2nd experiment, that is, a WIDE backbone IPv6 network through IPv6 L2TP over the NTT NGNv6 PPPoE service. DNS v4, DNSv6, DNS64, NAT64 and web servers for local information were settled in the server segment of this core network by dual stack fashion with DNS load balancing. DHCP4, DHCP6, Radius, CISCO's WLC and WCS, STUN and TURN servers were also settled in this server segment. IPv6 connectivity with DNS64/NAT64 was provided through other two Hazeyama, et al. Expires September 14, 2012 [Page 10] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 experiments, LISP/VXLAN experiment and OSLR based Layer 3 mesh wi-fi experiment. As a backup plan, we prepared a dual stack environment for users in wired access. Of course, this dual stack was able to be served in wireless access. Actually, we provided this dual stack network to participants through layer 2 mesh wi-fi during the closing session in March 8th. We also constructed two IPv6 networks based on commercial IPv6 services which are available by home users in Japan. One was 2409: 150:8000::/48 IPv6 network through NTT NGNv6 IPoE method (labeled native IPoE), the other was 2001:240:2002:6d00::/56 IPv6 network through NTT NGNv6 PPPoE method (named native PPPoE). Basically, these two IPv6 networks were pure IPv6 networks, therefore, we served them with the DNS64/NAT64 service on the camp core network through DNS load balancing by F5 Big IP. NTT Advanced Technology supported to set up this DNS load balancing. On the evening of 3rd day (March 7th), we prepared a rouge AP to test DoS attacks to IPv6 clients. The rogue AP did not provide any Internet connectivity, and attacked wi-fi clients by massive RA announcement. 3.2. IPv4 networks Three IPv4 network services were provided in the 2nd experiment, SA46T, 4RD and 464XLAT. Different from the 1st experiment, both SA46T and 4RD were provided as pure IPv4 network services in this 2nd experiment. SA46T provided a global IPv4 network of WIDE backbone with three SA46T implementations and with DNS v4 service of the core network in the camp. The SA46T gateway on the WIDE backbone was Keio university implementation (SA46T-KO), on the other hand, two implementations of SA46T by Fujitsu group (SA46T-FA and SA46T-FK) were employed in the Matsushiro Royal Hotel. 4RD served a private IPv4 network where the 4RD-BR was settled on an experimental network of IIJ. The 4RD-CE played NAPT and DNS v4 proxy. Both 4RD-BR and 4RD-CE were IIJ SEIL router implementations [SEIL]. The 4RD network was operated by IIJ. 464 XLAT, which is now under a field trial of JPIX, was operated by JPIX and NEC AccessTechnica. 464XLAT provided a pure global IPv6 network service and a private IPv4 NAT service. CLAT, which is a client side translator of 464XLAT, ran as IPv6 gateway, a stateless translator [RFC6145], and DNS v4/v6 proxy. Each transition technology has limitation on available protocols, Hazeyama, et al. Expires September 14, 2012 [Page 11] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 fragmentation support, and so on. One of purposes of this 2nd experiment was to grasp these limitations and reasons of each limitation. 3.3. DNS Settings Table Table 1 shows the DNS settings of each network. On the core network, F5 Big IP was placed as a DNS load balancer (203.178.159.58, 2001:200:0:ff60::58), which simply forwarded AAAA queries from native IPoE, native PPPoE and dual stack to DNS64 (2001:200:0:ff60::6), transferred A queries under the SA46T service on the camp to DNS4 (203.178.159.2) and redirected queries from the out of the camp to nons.wide.ad.jp. DNS4, DNS6 and DNS64 ran on a same physical server on the server segment. ISC BIND was employed as the DNS64. The DNS64 was configured as a just forward only server which did not send recursive queries by itself, that is, the DNS64 server referred other DNS recursive resolver. We also prepared ISC BIND and NLNetLab Unbound for recursive resolvers to compare error messages related with [RFC4074]. The recursive resolver referred from the DNS64 was changed from ISC BIND server to Unbound server at the midnight of March 5th because the error check rules of Unbound server was more loose than that of ISC BIND, thus, we chose the Unbound server to reduce unnecessary error messages on syslog. Basically, DNS settings were transferred to users devices through DHCP4 or DHCP6. When a user's device did not have DHCP6 capability such as Mac OS X Snow Leopard or older, we let the user to set 2001: 200:0:ff60::58 or 2001:200:0:ff60::6 manually. In 4RD segments and 464XLAT segments, CE routers ran as DNS proxy to name servers on VNE or ISP, or the open name server of Google. Hazeyama, et al. Expires September 14, 2012 [Page 12] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +----------------------------+--------------------------------------+ | Network | DNS settings | +----------------------------+--------------------------------------+ | Dual Stack, Manual | 203.178.159.53, 2001:200:0:ff60::53 | | settings for older OSes | (DNS load balance) | | -------------------------- | ------------------------------------ | | LISP | 2001:200:0:ff60::6 (DNS64) | | -------------------------- | ------------------------------------ | | L3 mesh | 2001:200:0:ff60::6 (DNS64) | | -------------------------- | ------------------------------------ | | native IPoE | 2001:200:0:ff60::53 (DNS load | | | balance) | | -------------------------- | ------------------------------------ | | native PPPoE | 2001:200:0:ff60::53 (DNS load | | | balance) | | -------------------------- | ------------------------------------ | | SA46T (SA46T-FA, SA46T-FK) | 203.178.159.53 (DNS load balance) | | -------------------------- | ------------------------------------ | | 4RD (4RD/IPoE, 4RD/PPPoE) | 210.130.1.1 (via proxy) | | -------------------------- | ------------------------------------ | | 464XLAT/IPoE | 2404:1a8:7f01:b::3 (primary), | | | 2001:4860:4860::8888 (secondary) | | -------------------------- | ------------------------------------ | | 464XLAT/PPPPoE | 2001:240::13 (primary), | | | 2001:4860:4860::8888 (secondary) | +----------------------------+--------------------------------------+ Table 1: DNS settings 3.4. NAT64 Settings We prepared two NAT64 implementations in the core network. One was linuxnat64 which ran on the same physical server of DNS64. The other was F5 Big IP's NAT64 function. linuxnat64 based NAT64 service was provided from 10:00 of March 5th. F5 Big IP's NAT64 function was introduced from 22:00 of March 7th. 3.5. Wireless networks Eight networks (native IPoE, native PPPoE, 4RD/IPoE, 4RD/PPPoE, 464XLAT/IPoE, 464XLAT/PPPoE, SA46T-FA, SA46T-KF) were served to participants of the camp through CISCO L2 mesh Wi-Fi with WPA TKIP. Table Table 2 shows the served networks in each time slot. The evening of March 7th (From 18:00 of March 7th to 5:00 of March 8th), we arranged networks for two additional tests. One was fallback by closed IPv6 network of NTT NGNv6 in the 4RD/PPPoE environment. The other was 4RD/IPoE served through IEEE 11b wi-fi for commercial portable game devices (Nintendo DS / 3DS, Sony PSP / PSVita). Hazeyama, et al. Expires September 14, 2012 [Page 13] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 As mention above, the NOC team also had other two experiments in wireless networks, LISP/VXLAN experiment on CISCO managed Wi-Fi and of OSLR based layer 3 mesh wi-fi experiment. Both networks served IPv6 only network with DNS64/NAT64 services of the camp. Due to the out of scope on this document, we do not explain the details of other two experiments. +------------+--------------+--------------+---------------+--------+ | Time Slot | ESSID 1 | ESSID 2 | ESSID 3 | ESSID | | | | | | 4 | +------------+--------------+--------------+---------------+--------+ | 13:00 Mar. | 464XLAT/IPoE | 4RD/IPoE | native IPoE | - | | 5th to | | | | | | 17:30 Mar. | | | | | | 5th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | | 18:00 Mar. | native IPoE | native PPPoE | 4RD/PPPoE | - | | 5th to | | | | | | 12:00 Mar. | | | | | | 6th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | | 12:30 Mar. | L3 mesh | SA46T-FA | 464XLAT/PPPoE | native | | 6th to | (IPv6) | | | IPoE | | 17:30 Mar. | | | | | | 6th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | | 18:00 Mar. | native PPPoE | 464XLAT/IPoE | SA46T-FK | - | | 6th to | | | | | | 12:00 Mar. | | | | | | 7th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | | 12:30 Mar. | native PPPoE | 4RD/IPoE | native IPoE | - | | 7th to | | | | | | 17:30 Mar. | | | | | | 7th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | | 18:00 Mar. | 4RD/PPPoE | 4RD/IPoE on | native IPoE | rogue | | 7th to | with closed | IEEE 11b | | | | 5:00 Mar. | IPv6 | | | | | 8th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | | 5:00 Mar. | dual stack | - | - | - | | 8th to | (WIDE) | | | | | 12:00 Mar. | | | | | | 8th | | | | | | ---------- | ------------ | ------------ | ------------- | ------ | +------------+--------------+--------------+---------------+--------+ Hazeyama, et al. Expires September 14, 2012 [Page 14] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 Table 2: Time Slot of served networks through layer 2 mesh Wi-Fi 3.6. Settings for MTU and NAT / Firewall Traversal Tests for commercial (P2P) Network Games Evaluating MTU and NAT / Firewall Traversal Tests on each test network for commercial (P2P) Network Games, Konami Digital Entertainment (KDE) experiment team placed STUN [RFC5389] and TURN [RFC5766] servers in the server segment of the camp core network. KDE prepared test clients, for testing IPv4 NAT/Firewall traversal from the view of consumer games. Test clients accessed to STUN / TURN servers and evaluated whether each network satisfied requirements from network games or not. The evaluation results will be explained in section 4 of this document. 4. Experiences from the Experiments 4.1. User Survey by face-to-face interview Here, we reports results of user survey. The user Survey was conducted in face-to-face interview fashion. We interviewed 166 participants about brought devices and their OSes. We also asked about the availability of networks, troubles or inconveniences. Because implementations of 4RD, 464XLAT, SA46T were designed along with performance specifications for home users, maximum users on each implementation without heavy load were around 50 clients to 80 clients. Participants were likely to move another network when they felt congestion or heavy load. Therefore, number of users on each network was balanced to each other, around 50 to 80. 4.1.1. Client Profile At the 2nd experiment, 297 unique devices were identified from 166 participants. This shows one participants brought two or more devices. Typical participants took a normal personal computer and a smart-phone or a similar personal device such as iPod touch, iPad, Kindle, portable game devices. Table. Table 3 shows distributions of Devices. Table. Table 4 shows distributions of OSes. We also profiled applications on these devices. We looked over lots of applications but some of them had problems due to lack of applicability to IPv6 and its network characteristic. All problematic cases were as same as reported in the 1st camp. The worst case was that we saw an application was crashed. The lack of applicability to IPv6 can be summarized as bellow. Any kind of VPN has a propensity for getting into accidents. Hazeyama, et al. Expires September 14, 2012 [Page 15] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +-------------------+--------------------------------+ | Devices | # of participants (percentage) | +-------------------+--------------------------------+ | Personal Computer | 140 (47.1 %) | | ----------------- | ------------------------------ | | Tablet PC | 23 (7.7 %) | | ----------------- | ------------------------------ | | Smart Phone | 114 (38.4 %) | | ----------------- | ------------------------------ | | Game Devices | 19 (6.4 %) | | ----------------- | ------------------------------ | | Others | 1 (0.3 %) | +-------------------+--------------------------------+ Table 3: The distributions of devices of participants +---------------------------+---------------------------+ | OS | # of devices (percentage) | +---------------------------+---------------------------+ | Android | 37 (12.5 %) | | ------------------------- | ------------------------- | | Android 2.2 | 2 (9.7 %) | | ------------------------- | ------------------------- | | Android 2.3 | 3 (1.0 %) | | ------------------------- | ------------------------- | | Android 2.3.4 | 2 (0.7 %) | | ------------------------- | ------------------------- | | Android 4.0.2 | 1 (0.3 %) | | ------------------------- | ------------------------- | | Android 4.0.3 | 1 (0.3 %) | | ------------------------- | ------------------------- | | Arch Linux | 1 (0.3 %) | | ------------------------- | ------------------------- | | blackberry | 1 (0.3 %) | | ------------------------- | ------------------------- | | CentOS | 1 (0.3 %) | | ------------------------- | ------------------------- | | Debian | 1 (0.3 %) | | ------------------------- | ------------------------- | | FreeBSD | 1 (0.3 %) | | ------------------------- | ------------------------- | | iOS 4.3.2 JB | 1 (0.3 %) | | ------------------------- | ------------------------- | | iPad iOS | 21 (7.1 %) | | ------------------------- | ------------------------- | | iPhone iOS | 59 (19.9 %) | | ------------------------- | ------------------------- | | iPod Touch iOS | 11 (3.7 %) | Hazeyama, et al. Expires September 14, 2012 [Page 16] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 | ------------------------- | ------------------------- | | Kindle | 1 (0.3 %) | | ------------------------- | ------------------------- | | Linux Open WRT 2.7.39 | 1 (0.3 %) | | ------------------------- | ------------------------- | | Mac OS X Lion | 48 (16.2 %) | | ------------------------- | ------------------------- | | Mac OS X Snow Leopard | 31 (10.4 %) | | ------------------------- | ------------------------- | | NetBSD 5.1 | 1 (0.3 %) | | ------------------------- | ------------------------- | | Nokia 5800 | 1 (0.3 %) | | ------------------------- | ------------------------- | | PSP | 2 (0.7 %) | | ------------------------- | ------------------------- | | PS Vita | 1 (0.3 %) | | ------------------------- | ------------------------- | | Ubuntu | 4 (1.3 %) | | ------------------------- | ------------------------- | | WiMAX Router | 1 (0.3 %) | | ------------------------- | ------------------------- | | Windows Vista | 4 (1.3 %) | | ------------------------- | ------------------------- | | Windows XP | 11 (3.7 %) | | ------------------------- | ------------------------- | | Windows 7 | 35 (11.8 %) | | ------------------------- | ------------------------- | | Windows Mobile | 3 (1.0 %) | | ------------------------- | ------------------------- | | Nintendo DS / 3DS (0.3 %) | 3 (1.0 %) | +---------------------------+---------------------------+ Table 4: The distributions of Operating Systems on participants' devices 4.1.2. Reported Troubles Here, we explain reported troubles or inconveniences of participants on network connectivity. There troubles / inconveniences were reported by participants through face-to-face interview or comments on a wiki. 4.1.2.1. Failure of IPv6 neighbor discovery due to the on-link assumption of IPv4 network In the IPv6 single stack LAN, although 169.254/16 IPv4 Link Local Address[RFC3927] was assigned to an interface, some devices tried to get IPv4 address by DHCP4 and failed IPv6 neighbor discovery due to Hazeyama, et al. Expires September 14, 2012 [Page 17] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 the DHCP4 failure. In this case, the IPv6 network was never available by the participant, therefore, they were likely to move to another network where an IPv4 private/global address was assigned. That is, IPv4 DHCP Discovery along with on-link assumption of IPv4 network blocked IPv6 Neighbor Discovery. The similar harmful behavior on IPv6 Neighbor Discovery along with on-link assumption in IPv4 only network has been described in [RFC4943]. We need further evaluation and discussion on this IPv4 case. 4.1.2.2. Locked out IPv6 by vendor There were two devices which were made different hardware but equipped same OS with same version. These two devices were also subscribed with a same mobile company and had a same behavior to the IPv4. However, the one can get IPv6 address over WiFi network and the other can not do so. The OS was announced that has IPv6 capability from the OS vendor. In this case, we suspected that the hardware vendor may lock out IPv6 function. We should have further examinations on this trouble. 4.1.2.3. Inappropriate selection of DNS resolvers We observed inappropriate DNS resolver settings on resolve.conf of several clients, for example, the DNS resolver address was never reached from a client without translators. These inappropriate DNS resolver settings were caused by careless mistake on DHCP6 and RA settings due to lack of understanding on appropriate name servers on a network. Once this trouble occurred, it was hard for users to comprehend and to deal with it. If the ULA (Unique Local global unicast Address [RFC4193]) was used, it might be getting more complicated. 4.1.2.4. Previous configuration lived after moving to another WiFi network With some of latest OSes, participants had a trouble on network configuration in the client PC. The trouble of network configuration would be caused that the OS kept the previous network information and could not renew after getting into another WiFi network. This trouble was hard to be solved, when the trouble on mis-configuration of name servers (section Section 4.1.2.3) occurred at the same time. 4.1.2.5. Crash of an application by plug-in An IPv4 depended plugin crashed an application. Unawareness of dual stack for application programmers may occur serious problems before Hazeyama, et al. Expires September 14, 2012 [Page 18] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 IPv6 deployment. It is more important to share what is dual stack network and functions for dual stack communications. 4.1.2.6. Happy Eyeball implementation with turn-on/off switch Happy eyeball implementation which enables faster communication with IPv4 Internet is very effective if the IPv6 network is not available or the IPv6 network becomes slow down than an IPv4 network. However, when an IPv6 network is faster than an IPv4 network, the Happy eyeball function may decrease the performance of web browsing. Therefore, some implementations of Happy Eyeball equip turn-on/off switch. However, such turn-on/off switch usually requires parameter settings and parameter settings are difficult. Actually, network engineers in the 2nd experiment had difficulty on parameter tuning of Happy Eyeball. Network engineers on the 2nd experiment worried about that average or novice users could not use well current turn-on/off switch implementation of Happy Eyeball. 4.1.2.7. Different behavior among OSes on MTU handling In the 1st experiment, several participant claimed download of big data did not work through PPTP access over SA46T. To verify the cause of this problem, we evaluated communications to servers through PPTP access over SA46T by Windows 7 and Mac OS Lion in this 2nd experiment. Test servers were a CISCO UCS server to download remote KVM java program and a linux server accessed by ssh. Then, the data transfer on Windows 7 worked well both on access to the CISCO UCS server and on the linux server. On the other hand, that on Mac OS Lion stopped in a few minutes neither the CISCO UCS server nor on the linux server. To clarify that whether the difference derived from MTU size or not, we evaluate ping program on each OS with changing payload size and DF bit value. In Windows 7, ``ping -l 1500'' worked and ``ping -l 1500 -f'' did not work. On the other hand, in Mac OS Lion, ``ping -s '' stopped around from 1411 to 1416. This result implies that MTU / fragmentation handling between Windows 7 and Mac OS Lion are different, and that MTU / fragmentation handling of Mac OS Lion may not be suit to IPv4 / IPv6 transition situation. We could not determine root cause of this trouble during the 2nd experiment, because of SA46T fragment functions. Three SA46T implementations were employed in 2nd experiment and they had different packet fragmentation support shown in section Section 4.2. Therefore, we could not remove the influence from lack of fragmentation support of one of SA46T implementation. We have to Hazeyama, et al. Expires September 14, 2012 [Page 19] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 verify difference of behaviors on packet fragmentation among OSes with further experiments. 4.2. MTU and NAT Traversal Tests for Network Games Here, we explain the result of MTU and NAT Traversal Tests by KDE experiment team. The test patterns were designed according to [RFC4787] as follows; o Address and Port Mapping Behavior o Port Assignment Behavior o Filtering Behavior o Hairpinning Behavior o Fragmentation of Outgoing Packets o Receiving Fragmented Packets These items were tested by KDE's test clients through STUN protocols defined in [RFC5389] and in [RFC5780]. Clients sent UDP packets to the STUN server along with test scenarios. 4.2.1. Between a Client and the STUN Server Table Table 5 shows test items by a client. Table Table 6, Table Table 7, Table Table 8 and Table Table 9 shows MTU and NAT Traversal test results on each network. The SA46T results in Table Table 8 and Table Table 9 derived from the difference among implementations on fragment support function. Hazeyama, et al. Expires September 14, 2012 [Page 20] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +------------------+------------------------------------------------+ | Elements | Definition | +------------------+------------------------------------------------+ | NAT | Exist: NAT exists, - : no NAT | | ---------------- | ---------------------------------------------- | | Mapping | Good or Bad : Good / Bad Behavior for P2P Game | | ---------------- | ---------------------------------------------- | | Filtering | Good or Bad : Good / Bad Behavior for P2P Game | | ---------------- | ---------------------------------------------- | | RTT | Round Trip Time (msec.) | | ---------------- | ---------------------------------------------- | | MTU size from | size (byte) | | client to server | | | ---------------- | ---------------------------------------------- | | Fragmentation | OK or NG : whether a big packet (DF=0) can be | | from client to | sent from a client to the server with | | server | fragmentation or not. | | ---------------- | ---------------------------------------------- | | MTU size from | size (byte) | | server to client | | | ---------------- | ---------------------------------------------- | | Fragmentation | YES or NO : whether a big packet (DF=0) can be | | from server to | sent from the server to a client with | | client | fragmentation or not. | +------------------+------------------------------------------------+ Table 5: Test Elements of NAT, Mapping, Filtering ( RFC 4787 ) / RTT / MTU Hazeyama, et al. Expires September 14, 2012 [Page 21] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +-----------------+-------------------+------------------+ | Elements | native PPPoE (v6) | native IPoE (v6) | +-----------------+-------------------+------------------+ | NAT | - | - | | --------------- | ----------------- | ---------------- | | Mapping | - | - | | --------------- | ----------------- | ---------------- | | Filtering | - | - | | --------------- | ----------------- | ---------------- | | RTT | 117 | 75 | | --------------- | ----------------- | ---------------- | | MTU size C => S | 1452 | 1500 | | --------------- | ----------------- | ---------------- | | Frag. C => S | YES | YES | | --------------- | ----------------- | ---------------- | | MTU size S => C | 1500 | 1500 | | --------------- | ----------------- | ---------------- | | Frag. S => C | YES | YES | +-----------------+-------------------+------------------+ Table 6: NAT Traversal Test Results between a Client and STUN Server (global IPv6) +-----------------+-------------------+------------------+ | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | +-----------------+-------------------+------------------+ | NAT | Exist | Exist | | --------------- | ----------------- | ---------------- | | Mapping | Bad | Good | | --------------- | ----------------- | ---------------- | | Filtering | Good | Good | | --------------- | ----------------- | ---------------- | | RTT | 156 | 323 | | --------------- | ----------------- | ---------------- | | MTU size C => S | 1452 | 1452 | | --------------- | ----------------- | ---------------- | | Frag. C => S | NO | NO | | --------------- | ----------------- | ---------------- | | MTU size S => C | 1280 | 1452 | | --------------- | ----------------- | ---------------- | | Frag. S => C | YES | YES | +-----------------+-------------------+------------------+ Table 7: NAT Traversal Test Results between a Client and STUN Server on 4RD Hazeyama, et al. Expires September 14, 2012 [Page 22] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +-----------------+--------------------+-------------------+ | Elements | 464XLAT/PPPoE (v4) | 464XLAT/IPoE (v4) | +-----------------+--------------------+-------------------+ | NAT | Exist | Exist | | --------------- | ----------------- | ---------------- | | Mapping | Good | Good | | --------------- | ----------------- | ---------------- | | Filtering | Good | Good | | --------------- | ----------------- | ---------------- | | RTT | 119 | 464 | | --------------- | ----------------- | ---------------- | | MTU size C => S | 1260 | 1476 | | --------------- | ----------------- | ---------------- | | Frag. C => S | YES | YES | | --------------- | ----------------- | ---------------- | | MTU size S => C | 1260 | 1480 | | --------------- | ----------------- | ---------------- | | Frag. S => C | YES | YES | +-----------------+--------------------+-------------------+ Table 8: NAT Traversal Test Results between a Client and STUN Server on 464XLAT +-----------------+------------------------+------------------------+ | Elements | SA46T-FA (v4) | SA46T-FK (v4) | +-----------------+------------------------+------------------------+ | NAT | - | - | | --------------- | ---------------------- | ---------------------- | | Mapping | - | - | | --------------- | ---------------------- | ---------------------- | | Filtering | - | - | | --------------- | ---------------------- | ---------------------- | | RTT | 112 | 76 | | --------------- | ---------------------- | ---------------------- | | MTU size C => S | 1460 | 1460 | | --------------- | ---------------------- | ---------------------- | | Frag. C => S | YES | NO (lack of frag. | | | | func. on SA46T-FK) | | --------------- | ---------------------- | ---------------------- | | MTU size S => C | NO (lack of frag. | NO (lack of frag. | | | func. on SA46T-KO) | func. on SA46T-KO) | | --------------- | ---------------------- | ---------------------- | | Frag. S => C | NO (due to SA46T-KO) | NO (due to SA46T-KO) | +-----------------+------------------------+------------------------+ Table 9: NAT Traversal Test Results between a Client and STUN Server on SA46T Hazeyama, et al. Expires September 14, 2012 [Page 23] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 4.2.2. Between Clients with NAT +---------------+-------------+-------------------------------------+ | Network | Protocol | Connectivity | +---------------+-------------+-------------------------------------+ | native PPPoE | IPv6 | Good (no NAT) | | ----------- | ----------- | ----------- | | native IPoE | IPv6 | Good (no NAT) | | ----------- | ----------- | ----------------------------------- | | 4RD/PPPoE | IPv4 | Bad (Address and Port dependent | | | | mapping) | | ----------- | ----------- | ----------------------------------- | | 4RD/IPoE | IPv4 | Bad (no hairpinning) | | ----------- | ----------- | ----------------------------------- | | 464XLAT/PPPoE | IPv4 | Bad (no hairpinning) | | ----------- | ----------- | ----------------------------------- | | 464XLAT/IPoE | IPv4 | Bad (no hairpinning) | | ----------- | ----------- | ----------------------------------- | | SA46T-FA | IPv4 | Good (no NAT) | | ----------- | ----------- | ----------------------------------- | | SA46T-FK | IPv4 | Good (no NAT) | +---------------+-------------+-------------------------------------+ Table 10: P2P connectivity between Clients on each IPv6 or IPv4 network 4.3. Analysis of inappropriate authoritative servers from DNS64 Log We analyzed DNS64 log to grasp inappropriate authoritative servers for DNS64. DNS64 will fall back to A record query when an authoritative server returns AAAA query with ``NOERROR ANSWER=0''. DNS64 fails to fallback A record query when an authoritative server returns inappropriate AAAA record mentioned in [RFC4074]. Also, [RFC6147] says Any other RCODE is treated as though the RCODE were 0 and the answer section were empty. This is because of the large number of different responses from deployed name servers when they receive AAAA queries without a AAAA record being available. Note that this means, for practical purposes, that several different classes of error in the DNS are all treated as though a AAAA record is not available for that owner name. It is important to note that, as of this writing, some servers respond with RCODE=3 to a AAAA query even if there is an A record available for that owner name. Those servers are in clear violation of the meaning of RCODE 3, and it is expected that they will decline in use as IPv6 deployment increases. Hazeyama, et al. Expires September 14, 2012 [Page 24] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 In the 2nd experiment, we analyzed that distributions of error messages of AAAA queries, and that whether number of error messages are changed by DNS implementations or not. The name server settings of the camp were as follows; F5 BIG-IP forwarded queries to DNS64 server except ``www.camp.wide.ad.jp''. DNS64 server only forwarded queries to Unbound/BIND resolver and did not do any iterative queries by itself We have changed target resolver from bind server to unbound server at midnight on March 5th We analyzed DNS64's error messages recorded in March 5th when DNS64 forwarded queries to the BIND resolver. Table Table 11 shows number of unique authoritative servers in each error message. Most error messages of BIND resolver were FormError. Comparing differences between implementations, we recheck FormError authoritative servers by Unbound. The result is shown in Table Table 12. According to these result, BIND is more restrict to ``bogus'' response than Unbound. For example, BIND was denied about AAAA query for *.wikipedia.org, on the other hand, Unbound was allowed. Of course, we observed several web site URLs which both BIND and Unbound were denied on AAAA queries. Table Table 13 shows recheck result by both BIND and Unbound on all error messages of DNS64 during the camp (From March 5th to the end of closing of March 8th). Number of NXDOMAIN to AAAA, whose A record exist, was abnormal response that indicated failure of fallback to A query on DNS64. Such abnormal AAAA responses was returned to 69 queries in Unbound case, 201 AAAA queries in BIND case. +-------------------+-----------------------------------+ | Error Type | # of unique authoritative servers | +-------------------+-----------------------------------+ | Refused | 47 | | ----------------- | ------------------------------ | | ServFail | 66 | | ----------------- | ------------------------------ | | FormError | 554 | +-------------------+-----------------------------------+ Table 11: The distributions of error messages Hazeyama, et al. Expires September 14, 2012 [Page 25] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 +-----------------+-----------------------+-------------------------+ | Error Type | # of unique auth. | # of unique auth. | | | servers (BIND) | servers (Unbound) | +-----------------+-----------------------+-------------------------+ | NXDOMAIN | 449 | 21 | | --------- | --------- | --------- | | NOERROR Record | 66 | 506 | | = 0 | | | | --------- | --------- | --------- | | NOERROR Record | 9 | 7 | | > 0 | | | | --------- | --------- | --------- | | Others (ex. no | 11 | 20 | | reply) | | | +-----------------+-----------------------+-------------------------+ Table 12: Verification FormError of BIND by Unbound +-------------------------------------------------------+-----------+ | | number | +-------------------------------------------------------+-----------+ | # of names (A, AAAA, PTR, SRV( | 70886 | | --------- | --------- | | # of names queried by AAAA | 45633 | | --------- | --------- | | # of NXDOMAIN by AAAA from Unbound | 4011 | | --------- | --------- | | # of names which A record exist althogh an auth. | 69 | | server returned NXDOMAIN by AAAA from Unbound | | | # of NXDOMAIN by AAAA from Unbound | 4011 | | --------- | --------- | | # of NXDOMAIN by AAAA from BIND | 4234 | | --------- | --------- | | # of names which A record exist althogh an auth. | 201 | | server returned NXDOMAIN by AAAA from BIND | | +-------------------------------------------------------+-----------+ Table 13: Statistics of DNS through the camp 5. Open Issues 5.1. Dependency between IPv4 and IPv6 address configuration In this 2nd experiment, we observed troubles due to the dependency between IPv4 and IPv6 address configuration. We think, both IPv4 and IPv6 address configuration SHOULD work independently in a device or an OS. Hazeyama, et al. Expires September 14, 2012 [Page 26] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 5.2. PMTUD, MTU mismatch problems and NAT behavior problems Through the 2nd experiment, we recognized that PMTUD, MTU mismatch problems may be caused not only from lack of fragment support of network devices but also difference among OSes' behaviors on MTU / packet size handling. Although we tested the difference between Windows 7 and Mac OS Lion on access to a linux server over PPTP through SA46T networks, we did not clarify the reason why Mac OS X Lion had MTU mismatch that Windows 7 did not face. PMTUD, MTU mismatch problems SHOULD be evaluated through further evaluation. KDE's evaluation results indicates that game applications need fragment support by network devices and/or OSes. KDE's evaluation results also implies that transition technologies which do not provide hairpinning behavior or and Endpoint Independent Mapping behavior through IPv6 backbones may not satisfy requirements from consumer game products. All members of the 2nd experiment team felt that PMTUD, MTU mismatch problems are quite serious, and that IETF working groups SHOULD reconsider PMTUD, MTU mismatch problems and SHOULD seek more practical solution on the current situation. 5.3. Workaround for DNS64 problems As same as the 1st experiment, we met inappropriate DNS authoritative servers' behaviors on AAAA queries. Although the fundamental solution is requesting a correction to the administrator who manages such 'broken' authoritative server. Actually, Several DNS servers, which returned inappropriate AAAA replies on the 1st experiment, were fixed appropriately. The other work-around solutions that change the algorithm of DNS64 can be considered. 5.3.1. Workaround for illegal NameError Even when the result of a query of AAAA record is RCODE 3, ask A record, and transform the result of A record to the AAAA record. Then, the AAAA record which is converted from A record is cached. This workaround makes additional queries when client sends a query for the name which has *no* records. Nevertheless, these results are cached, hence DNS64 server does not make extend queries too much. 5.3.2. Workdaround for lame delegation When an authority server is not found (no servers specified as an authoritative server, or server doesn't return responses with AA bit), A record is asked without returning ServFail and the result of A record is transformed. The AAAA record which is converted from A Hazeyama, et al. Expires September 14, 2012 [Page 27] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 record is cached same as section Section 5.3.1. Assuming If there is no authorized A record reply. DNS64 server sends ServFail to the client, and does not cache these records. Workaround B makes additional queries when client sends a query to the zone which has lame delegation. 6. 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. This experiment was the second trial on availability test of the IPv6 only connectivity with participants by WIDE Project. Many participants replied good impressions, however, various issues were more clarified through this experiment. Through these two experiments, we aware that trouble shooting is very hard where multiple protocols are running. Experiment team prepared several testing tools, however, they were not enough to discover of causes of troubles. A standard method of trouble shooting in such network condition, criteria, and a touchstone program are needed. We continue to look out for the problematic cases and discuss among internet community for the best practice. 7. Security Considerations As well as Arkko mentioned in [I-D.draft-arkko-ipv6-only-experience], 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. 8. IANA Considerations This document has no IANA implications. 9. References Hazeyama, et al. Expires September 14, 2012 [Page 28] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 9.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. 9.2. Informative References [I-D.draft-arkko-ipv6-only-experience] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", Febrary 2012, . [I-D.draft-ietf-v6ops-464xlat] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", March 2012, . [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] Hazeyama, et al. Expires September 14, 2012 [Page 29] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 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", January 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. [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. [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. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful", RFC 4943, September 2007. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Hazeyama, et al. Expires September 14, 2012 [Page 30] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, May 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 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. [SEIL] Internet Initiative Japan, "SEIL", September 2011, . [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(s) on the experiments. We also say thank you to whom serving implementations and services in the Matsushiro Royal Hotel. N. Matsuhira of Fujitsu for SA46T. Hazeyama, et al. Expires September 14, 2012 [Page 31] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 R. Nakamura of Keio Univ. for SA46T. H. Suenaga and K. Ooyatsu of IIJ for SEIL 4RD. JPIX and M. Kawashima of NEC AccessTechnica for 464XLAT. NTT-AT guys for providing BIG-IP and Pivot3, which does load balancing, DNS64, NAT64, and capturing all traffic. Y. Ueno of Keio Univ. for IPv6 L2TP implementation. R. Sato and M. Sato of Konami Digital Entertainment Co, Ltd. for NAT/ Firewall traversal testing. NTT EAST, Internet Multifeed, and IIJ for the commercial IPv6 service. Authors' Addresses Hiroaki Hazeyama NAIST Takayama 8916-5 Nara, Japan Phone: +81 743 72 5216 Email: hiroa-ha@is.naist.jp 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 Hazeyama, et al. Expires September 14, 2012 [Page 32] Internet-Draft IPv6 Experiments in the WIDE Camp March 2012 Osamu Nakamura WIDE Project 5322 Endo Kanagawa, Japan Email: osamu@wide.ad.jp Hazeyama, et al. Expires September 14, 2012 [Page 33]