idnits 2.17.1 draft-hazeyama-widecamp-ipv6-only-experience-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2012) is 4426 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-464xlat-01 == Outdated reference: A later version (-05) exists of draft-matsuhira-sa46t-applicability-02 == Outdated reference: A later version (-09) exists of draft-matsuhira-sa46t-as-01 == Outdated reference: A later version (-11) exists of draft-matsuhira-sa46t-gaddr-03 == Outdated reference: A later version (-03) exists of draft-matsuhira-sa46t-mcast-00 == Outdated reference: A later version (-03) exists of draft-matsuhira-sa46t-motivation-00 == Outdated reference: A later version (-11) exists of draft-matsuhira-sa46t-spec-04 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Hazeyama 3 Internet-Draft NAIST 4 Intended status: Informational R. Hiromi 5 Expires: September 14, 2012 Intec Inc. 6 T. Ishihara 7 Univ. of Tokyo 8 O. Nakamura 9 WIDE Project 10 March 13, 2012 12 Experiences from IPv6-Only Networks with Transition Technologies in the 13 WIDE Camp Spring 2012 14 draft-hazeyama-widecamp-ipv6-only-experience-01 16 Abstract 18 This document reports and discusses issues on IPv6 only networks and 19 IPv4/IPv6 transition technologies through our experiences on the 2nd 20 experiment on the WIDE camp. The second experiment was held from 21 March 4th to March 8th, 2012. We tried to live in commercial IPv6 22 networks with four kinds of IPv4/IPv6 transition technologies, DNS64/ 23 NAT64, 4RD, 464XLAT and SA46T. In this -01.txt aims to report results 24 of the 2nd experiment and to share issues / problems on the IPv4 / 25 IPv6 transition that we met. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.1. History of ``Live with IPv6 experiment'' on the WIDE 63 camp . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1.1.1. Summary of the 1st experiment . . . . . . . . . . . . 5 65 1.1.2. Abstract of the 2nd experiment . . . . . . . . . . . . 5 66 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 67 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 7 68 3. Network and Experiment Setup . . . . . . . . . . . . . . . . . 7 69 3.1. IPv6 networks . . . . . . . . . . . . . . . . . . . . . . 10 70 3.2. IPv4 networks . . . . . . . . . . . . . . . . . . . . . . 11 71 3.3. DNS Settings . . . . . . . . . . . . . . . . . . . . . . . 12 72 3.4. NAT64 Settings . . . . . . . . . . . . . . . . . . . . . . 13 73 3.5. Wireless networks . . . . . . . . . . . . . . . . . . . . 13 74 3.6. Settings for MTU and NAT / Firewall Traversal Tests 75 for commercial (P2P) Network Games . . . . . . . . . . . . 15 76 4. Experiences from the Experiments . . . . . . . . . . . . . . . 15 77 4.1. User Survey by face-to-face interview . . . . . . . . . . 15 78 4.1.1. Client Profile . . . . . . . . . . . . . . . . . . . . 15 79 4.1.2. Reported Troubles . . . . . . . . . . . . . . . . . . 17 80 4.1.2.1. Failure of IPv6 neighbor discovery due to the 81 on-link assumption of IPv4 network . . . . . . . . 17 82 4.1.2.2. Locked out IPv6 by vendor . . . . . . . . . . . . 18 83 4.1.2.3. Inappropriate selection of DNS resolvers . . . . . 18 84 4.1.2.4. Previous configuration lived after moving to 85 another WiFi network . . . . . . . . . . . . . . . 18 86 4.1.2.5. Crash of an application by plug-in . . . . . . . . 18 87 4.1.2.6. Happy Eyeball implementation with turn-on/off 88 switch . . . . . . . . . . . . . . . . . . . . . . 19 89 4.1.2.7. Different behavior among OSes on MTU handling . . 19 90 4.2. MTU and NAT Traversal Tests for Network Games . . . . . . 20 91 4.2.1. Between a Client and the STUN Server . . . . . . . . . 20 92 4.2.2. Between Clients with NAT . . . . . . . . . . . . . . . 24 93 4.3. Analysis of inappropriate authoritative servers from 94 DNS64 Log . . . . . . . . . . . . . . . . . . . . . . . . 24 95 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 5.1. Dependency between IPv4 and IPv6 address configuration . . 26 97 5.2. PMTUD, MTU mismatch problems and NAT behavior problems . . 27 98 5.3. Workaround for DNS64 problems . . . . . . . . . . . . . . 27 99 5.3.1. Workaround for illegal NameError . . . . . . . . . . . 27 100 5.3.2. Workdaround for lame delegation . . . . . . . . . . . 27 101 6. Conclusion and Future Work . . . . . . . . . . . . . . . . . . 28 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 104 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 108 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 111 1. Introduction 113 This document reports and discusses issues on IPv6 only networks and 114 IPv4/IPv6 transition technologies through our experiences on the 2nd 115 experiment on the WIDE camp. The 2nd experiment was held from March 116 5th to March 8th in Matsushiro Royal Hotel, Nagano, Japan, where is 117 the same hotel of the 1st experiment. 119 1.1. History of ``Live with IPv6 experiment'' on the WIDE camp 121 ``Live with IPv6 experiment'' aims to evaluate commercial IPv6 122 network services, the availability of IPv6 networks with several IPv4 123 / IPv6 translation / encapsulation technologies by actual users' 124 experiences, and to grasp issues on IPv4 exhaustion situation or IPv4 125 / IPv6 transition. This experiment is based on an assumption that 126 ISP backbone networks will be constructed on IPv6 only and end 127 customer will have to use an IPv6 network with 64 translators or an 128 IPv4 network with 464 translators to keep current usage of the 129 Internet services. 131 1.1.1. Summary of the 1st experiment 133 The 1st experiment was held in Matsushiro Royal Hotel from September 134 6th to September 9th, 2011 with 153 participants, and the experiment 135 result was reported in the v6ops BoF on IETF 82 Taipei. In the 1st 136 experiment, we constructed an IPv6 only network with NAT64 and DNS64 137 as a part of the WIDE backbone through IPv6 L2TP over a commercial 138 IPv6 network service. The commercial IPv6 network service was 139 provided by NTT-East as an Access Carrier, Internet MultiFeed as a 140 Virtual Network Enabler (VNE) and IIJ as an IPv6 Internet Service 141 Provider (IPv6 ISP). In addition to an IPv6 connectivity with NAT64/ 142 DNS64, we also tested a SA46T based IPv4 global network service and a 143 4RD based IPv4 private network service. With referring IETF's IPv6 144 only network experiences [I-D.draft-arkko-ipv6-only-experience], we 145 reported several new issues on an IPv6 only network with IPv4 / IPv6 146 transition technologies, especially on inappropriate DNS replies 147 mentioned in [RFC4074], on MTU mismatch, on VPN protocols and 148 applications through IPv4 / IPv6 translators. 150 1.1.2. Abstract of the 2nd experiment 152 According to the experiences on the 1st experiment, the 2nd 153 experiment was conducted from March 5th to March 8th, 2012 in 154 Matsushiro Royal Hotel, the same hotel of the 1st experiment. 171 155 participants joined this 2nd experiment, most of them were engineers 156 or academic people. The settings of the core network in the 2nd 157 experiment was same as the 1st experiment. In the 1st experiment, a 158 commercial IPv6 network service was employed as a backbone network, 159 in other word, we did evaluate the availability of commercial IPv6 160 network services from the view of home users. Therefore, the 161 evaluation target of the 2nd experiment was planned as living in 162 commercial IPv6 networks with IPv4 / IPv6 translation technologies or 163 IPv4 / IPv6 translation services. 165 The user access networks of the 2nd experiment were achieved by two 166 types of commercial IPv6 network services through the NTT NGNv6 167 access network, with four kinds of IPv4 / IPv6 translation 168 technologies. One of the two commercial IPv6 network services was 169 /48 prefix IPv6 network service through IPoE[RFC0894] on NTT NGNv6 170 (we name it ``native IPoE'' in this draft), the other was /56 prefix 171 IPv6 network service through PPPoE[RFC2516] on NTT NGNv6 (we label it 172 ``native PPPoE'' in this draft)[YasudaAPRICOT2011]. Both IPv6 173 networks were served from NTT-East, Internet MultiFeed and IIJ as 174 same as the 1st experiment. 176 Usually, IPv6 networks on both native IPoE and native PPPoE were 177 provided with only DNS v6 proxy. We constructed DNS64/NAT64 service 178 on the WIDE backbone and on the camp core network, and served it 179 through DHCP6[RFC3736][RFC6106] both on native IPoE and on native 180 PPPoE. 182 Along with the DNS64/NAT64 translation service, for aiming to 183 evaluate more practical approaches on the current commercial 184 environments, we tested three IPv4 services over IPv6 networks, 4RD, 185 SA46T and 464XLAT. We mainly served seven IP networks to 186 participants by combination of those networks and translation 187 services, that is, native IPoE with DNS64/NAT64, native PPPoE with 188 DNS64/NAT64, 4RD on both IPoE and PPPoE, 464XLAT on both IPoE and 189 PPPoE, SA46T on PPPoE. 191 Three evaluations were mainly conducted by the evaluation team, i) 192 user survey about the availability of each network through face to 193 face interview, ii) analysis of DNS behaviors to grasp inappropriate 194 behaviors mentioned in [RFC4074], iii) availability test of VPN 195 applications to analyze MTU problems or to grasp whether an 196 unavailability of VPN applications was intentional one due to the 197 specification of a translation technology or not. Also, Konami 198 Digital Entertainment (KDE) joined in this experiment, and evaluated 199 NAT/Firewall traversal testing on each IPv6 network or each 200 translator service from the view of commercial (P2P) Network Game 201 services. 203 1.2. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 2. Technology and Terminology 211 In this document, the following terms are used. "NAT44" refers to 212 any IPv4-to-IPv4 network address translation algorithm, both "Basic 213 NAT" and "Network Address/Port Translator (NAPT)", as defined by 214 [RFC2663]. 216 "Dual Stack" refers to a technique for providing complete support for 217 both Internet protocols -- IPv4 and IPv6 -- in hosts and routers 218 [RFC4213]. 220 "NAT64" refers to a Network Address Translator - Protocol Translator 221 defined in [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6147], 222 [RFC6384]. 224 "SA46T" refers to Stateless Automatic IPv4 over IPv6 Tunneling 225 defined in [I-D.draft-matsuhira-sa46t-motivation], 226 [I-D.draft-matsuhira-sa46t-as], [I-D.draft-matsuhira-sa46t-spec], 227 [I-D.draft-matsuhira-sa46t-gaddr], 228 [I-D.draft-matsuhira-sa46t-applicability], 229 [I-D.draft-matsuhira-sa46t-mcast]. 231 "4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure 232 defined in [I-D.draft-murakami-softwire-4rd]. 234 "464XLAT" refers to Combination of Stateful and Stateless Translation 235 defined in [I-D.draft-ietf-v6ops-464xlat]. 237 3. Network and Experiment Setup 239 The WIDE camp spring 2012 was held at Matsushiro Royal Hotel in 240 Nagano Prefecture of Japan, the same place of the 1st experiment, 241 from March 5th to March 8th, 2012. Figure Figure 1 shows the 242 overview of the test topology on the 2nd experiment, and Figure 243 Figure 2 and Figure Figure 3 represent details of the network in 244 Matsushiro Royal Hotel. 246 We, WIDE Project, set up the same IPv6 only network of the 1st 247 experiment held in September 2011 as a core network, dual stack and 248 SA46T on PPPoE through IPv6 L2TP tunnel with using WIDE backbone's 249 address blocks. Together with these core network settings by WIDE 250 Project, we added actual use cases of commercial IPv6 networks and 251 translation services with supports from a Japanese Access Carrier 252 (NTT-East), an ISP (IIJ), an IX (JPIX), a VNE (Internet MultiFeed), a 253 network equipment vendor (NEC AccessTechnica) and a SIer (NTT 254 Advanced Technology). 256 +-----------------------------------------------+ 257 | The Internet | 258 +-----------------------------------------------+ 259 | | | | 260 +------+ | | | | 261 | PLAT | | | | | 262 +------+ | | | | 263 | | | | | 264 +------+ | | | | 265 | JPIX |--+ | | | 266 +------+ | | | 267 | | | 268 +-----------+ | +------------+ 269 | IIJ (ISP) | | | WIDE (ISP) | 270 +-----------+ | +------------+ 271 | | | | | 272 +------+ +-----------+ | +-------+ 273 |4RD-BR| |MFeed (VNE)| +-------+ | SA46T | 274 +------+ +-----------+ |v6 L2TP| +-------+ 275 | +-------+ 276 +--------------------------------+ 277 | NTT NGNv6 (Access Line) | 278 +--------------------------------+ 279 | 280 +------------------------------------------------------------+ 281 | IPv6 test networks | 282 |+-PD Router-+ +---4RD-CE---+ +----CLAT----+ +---- L2TP ----+| 283 || IPv6 only | | 4RD | | 464XLAT | | SA46T | dual || 284 ||-----------| |------------| |------------| |--------------|| 285 ||IPoE |PPPoE| |IPoE | PPPoE| |IPoE | PPPoE| | PPPoE || 286 |+-----------+ +------------+ +------------+ +--------------+| 287 +------------------------------------------------------------+ 288 | 289 +------------------------------------------------------------+ 290 | Wi-fi Access (CISCO Layer 2 mesh, 11b/g/n Wi-fi) | 291 +------------------------------------------------------------+ 293 Over view of the 2nd experiment topology 295 Figure 1 297 +----------------+ 298 | NTT NGNv6 | 299 +----------------+ 300 |(NGN IPoE Access Service) 301 +--------+ 302 | ONU-48 | 2409:150:8000::/48 303 +--------+ 304 | 305 +--Flets IPv6 -------------+-----------------------------+ 306 | 307 |(v6) 308 +-------------+ 309 +---------------| PD Router |-------------+ 310 | +-------------+ | 311 | |(v6) | 312 | +-------+ +--------+ +--------+ 313 | | DHCP6 | | CLAT | | 4RD-CE | 314 | +-------+ +--------+ +--------+ 315 | | | | 316 | | | | 317 | | | | 318 +- global v6 -+ +- global v6 -+ +- private v4-+ 319 no ipv4 private v4 no v6 320 with with with 321 NAT64/DNS64 DNS v4/ v6 Proxy DNSv4 proxy 322 on the camp of CLAT of 4RD-CE 324 The Test Topology on NTT NGNv6 IPoE service 326 Figure 2 328 +-------------------+ 329 | IIJ PPPoE Service | 330 +-------------------+ 331 | (NGN PPPoE Access Service) 332 +--------+ 333 | ONU-56 | 334 +--------+ 335 | 336 +--IIJ PPPoE IPv6 -----+---------------- 2001:240:2002:6d00::/56 337 |(v6) 338 +-------------+ (v6) +---------+ 339 | PPPoE Client|------------------| v6 L2TP | 340 +------------| & PD router |---------+ +---------+ 341 | +-------------+ | | 342 |(v6) |(v6) |(v6) |(dual) 343 | +-------+ +--------+ +--------+ +--------+ 344 | | DHCP6 | | CLAT | | 4RD-CE | | router |---+ 345 | +-------+ +--------+ +--------+ +--------+ | 346 | | |(dual) |(v4) | +-dual stack-+ 347 | | | | | (WIDE) 348 | | | | | +-------+ 349 | | | | | | SA46T | 350 +- global v6 -+ +- global v6 -+ +- private v4-+ | +-------+ 351 no v4 private v4 no v6 | | 352 with with with | | +-----+ 353 DNS64/NAT64 DNS v4/v6Proxy DNS v4 Proxy | | |DHCP4| 354 on the camp of CLAT of 4RD-CE | | +-----+ 355 | | | 356 +-- global v4 --+ 357 no v6 358 with DNS4 359 on the camp 361 The Test Topology on NTT NGNv6 PPPoE service 363 Figure 3 365 3.1. IPv6 networks 367 The same IPv6 network of the 1st experiment was achieved as a core 368 network in the 2nd experiment, that is, a WIDE backbone IPv6 network 369 through IPv6 L2TP over the NTT NGNv6 PPPoE service. DNS v4, DNSv6, 370 DNS64, NAT64 and web servers for local information were settled in 371 the server segment of this core network by dual stack fashion with 372 DNS load balancing. DHCP4, DHCP6, Radius, CISCO's WLC and WCS, STUN 373 and TURN servers were also settled in this server segment. IPv6 374 connectivity with DNS64/NAT64 was provided through other two 375 experiments, LISP/VXLAN experiment and OSLR based Layer 3 mesh wi-fi 376 experiment. As a backup plan, we prepared a dual stack environment 377 for users in wired access. Of course, this dual stack was able to be 378 served in wireless access. Actually, we provided this dual stack 379 network to participants through layer 2 mesh wi-fi during the closing 380 session in March 8th. 382 We also constructed two IPv6 networks based on commercial IPv6 383 services which are available by home users in Japan. One was 2409: 384 150:8000::/48 IPv6 network through NTT NGNv6 IPoE method (labeled 385 native IPoE), the other was 2001:240:2002:6d00::/56 IPv6 network 386 through NTT NGNv6 PPPoE method (named native PPPoE). Basically, 387 these two IPv6 networks were pure IPv6 networks, therefore, we served 388 them with the DNS64/NAT64 service on the camp core network through 389 DNS load balancing by F5 Big IP. NTT Advanced Technology supported 390 to set up this DNS load balancing. 392 On the evening of 3rd day (March 7th), we prepared a rouge AP to test 393 DoS attacks to IPv6 clients. The rogue AP did not provide any 394 Internet connectivity, and attacked wi-fi clients by massive RA 395 announcement. 397 3.2. IPv4 networks 399 Three IPv4 network services were provided in the 2nd experiment, 400 SA46T, 4RD and 464XLAT. Different from the 1st experiment, both 401 SA46T and 4RD were provided as pure IPv4 network services in this 2nd 402 experiment. 404 SA46T provided a global IPv4 network of WIDE backbone with three 405 SA46T implementations and with DNS v4 service of the core network in 406 the camp. The SA46T gateway on the WIDE backbone was Keio university 407 implementation (SA46T-KO), on the other hand, two implementations of 408 SA46T by Fujitsu group (SA46T-FA and SA46T-FK) were employed in the 409 Matsushiro Royal Hotel. 411 4RD served a private IPv4 network where the 4RD-BR was settled on an 412 experimental network of IIJ. The 4RD-CE played NAPT and DNS v4 413 proxy. Both 4RD-BR and 4RD-CE were IIJ SEIL router implementations 414 [SEIL]. The 4RD network was operated by IIJ. 416 464 XLAT, which is now under a field trial of JPIX, was operated by 417 JPIX and NEC AccessTechnica. 464XLAT provided a pure global IPv6 418 network service and a private IPv4 NAT service. CLAT, which is a 419 client side translator of 464XLAT, ran as IPv6 gateway, a stateless 420 translator [RFC6145], and DNS v4/v6 proxy. 422 Each transition technology has limitation on available protocols, 423 fragmentation support, and so on. One of purposes of this 2nd 424 experiment was to grasp these limitations and reasons of each 425 limitation. 427 3.3. DNS Settings 429 Table Table 1 shows the DNS settings of each network. On the core 430 network, F5 Big IP was placed as a DNS load balancer (203.178.159.58, 431 2001:200:0:ff60::58), which simply forwarded AAAA queries from native 432 IPoE, native PPPoE and dual stack to DNS64 (2001:200:0:ff60::6), 433 transferred A queries under the SA46T service on the camp to DNS4 434 (203.178.159.2) and redirected queries from the out of the camp to 435 nons.wide.ad.jp. DNS4, DNS6 and DNS64 ran on a same physical server 436 on the server segment. 438 ISC BIND was employed as the DNS64. The DNS64 was configured as a 439 just forward only server which did not send recursive queries by 440 itself, that is, the DNS64 server referred other DNS recursive 441 resolver. We also prepared ISC BIND and NLNetLab Unbound for 442 recursive resolvers to compare error messages related with [RFC4074]. 443 The recursive resolver referred from the DNS64 was changed from ISC 444 BIND server to Unbound server at the midnight of March 5th because 445 the error check rules of Unbound server was more loose than that of 446 ISC BIND, thus, we chose the Unbound server to reduce unnecessary 447 error messages on syslog. 449 Basically, DNS settings were transferred to users devices through 450 DHCP4 or DHCP6. When a user's device did not have DHCP6 capability 451 such as Mac OS X Snow Leopard or older, we let the user to set 2001: 452 200:0:ff60::58 or 2001:200:0:ff60::6 manually. 454 In 4RD segments and 464XLAT segments, CE routers ran as DNS proxy to 455 name servers on VNE or ISP, or the open name server of Google. 457 +----------------------------+--------------------------------------+ 458 | Network | DNS settings | 459 +----------------------------+--------------------------------------+ 460 | Dual Stack, Manual | 203.178.159.53, 2001:200:0:ff60::53 | 461 | settings for older OSes | (DNS load balance) | 462 | -------------------------- | ------------------------------------ | 463 | LISP | 2001:200:0:ff60::6 (DNS64) | 464 | -------------------------- | ------------------------------------ | 465 | L3 mesh | 2001:200:0:ff60::6 (DNS64) | 466 | -------------------------- | ------------------------------------ | 467 | native IPoE | 2001:200:0:ff60::53 (DNS load | 468 | | balance) | 469 | -------------------------- | ------------------------------------ | 470 | native PPPoE | 2001:200:0:ff60::53 (DNS load | 471 | | balance) | 472 | -------------------------- | ------------------------------------ | 473 | SA46T (SA46T-FA, SA46T-FK) | 203.178.159.53 (DNS load balance) | 474 | -------------------------- | ------------------------------------ | 475 | 4RD (4RD/IPoE, 4RD/PPPoE) | 210.130.1.1 (via proxy) | 476 | -------------------------- | ------------------------------------ | 477 | 464XLAT/IPoE | 2404:1a8:7f01:b::3 (primary), | 478 | | 2001:4860:4860::8888 (secondary) | 479 | -------------------------- | ------------------------------------ | 480 | 464XLAT/PPPPoE | 2001:240::13 (primary), | 481 | | 2001:4860:4860::8888 (secondary) | 482 +----------------------------+--------------------------------------+ 484 Table 1: DNS settings 486 3.4. NAT64 Settings 488 We prepared two NAT64 implementations in the core network. One was 489 linuxnat64 which ran on the same physical server of DNS64. The other 490 was F5 Big IP's NAT64 function. linuxnat64 based NAT64 service was 491 provided from 10:00 of March 5th. F5 Big IP's NAT64 function was 492 introduced from 22:00 of March 7th. 494 3.5. Wireless networks 496 Eight networks (native IPoE, native PPPoE, 4RD/IPoE, 4RD/PPPoE, 497 464XLAT/IPoE, 464XLAT/PPPoE, SA46T-FA, SA46T-KF) were served to 498 participants of the camp through CISCO L2 mesh Wi-Fi with WPA TKIP. 499 Table Table 2 shows the served networks in each time slot. The 500 evening of March 7th (From 18:00 of March 7th to 5:00 of March 8th), 501 we arranged networks for two additional tests. One was fallback by 502 closed IPv6 network of NTT NGNv6 in the 4RD/PPPoE environment. The 503 other was 4RD/IPoE served through IEEE 11b wi-fi for commercial 504 portable game devices (Nintendo DS / 3DS, Sony PSP / PSVita). 506 As mention above, the NOC team also had other two experiments in 507 wireless networks, LISP/VXLAN experiment on CISCO managed Wi-Fi and 508 of OSLR based layer 3 mesh wi-fi experiment. Both networks served 509 IPv6 only network with DNS64/NAT64 services of the camp. Due to the 510 out of scope on this document, we do not explain the details of other 511 two experiments. 513 +------------+--------------+--------------+---------------+--------+ 514 | Time Slot | ESSID 1 | ESSID 2 | ESSID 3 | ESSID | 515 | | | | | 4 | 516 +------------+--------------+--------------+---------------+--------+ 517 | 13:00 Mar. | 464XLAT/IPoE | 4RD/IPoE | native IPoE | - | 518 | 5th to | | | | | 519 | 17:30 Mar. | | | | | 520 | 5th | | | | | 521 | ---------- | ------------ | ------------ | ------------- | ------ | 522 | 18:00 Mar. | native IPoE | native PPPoE | 4RD/PPPoE | - | 523 | 5th to | | | | | 524 | 12:00 Mar. | | | | | 525 | 6th | | | | | 526 | ---------- | ------------ | ------------ | ------------- | ------ | 527 | 12:30 Mar. | L3 mesh | SA46T-FA | 464XLAT/PPPoE | native | 528 | 6th to | (IPv6) | | | IPoE | 529 | 17:30 Mar. | | | | | 530 | 6th | | | | | 531 | ---------- | ------------ | ------------ | ------------- | ------ | 532 | 18:00 Mar. | native PPPoE | 464XLAT/IPoE | SA46T-FK | - | 533 | 6th to | | | | | 534 | 12:00 Mar. | | | | | 535 | 7th | | | | | 536 | ---------- | ------------ | ------------ | ------------- | ------ | 537 | 12:30 Mar. | native PPPoE | 4RD/IPoE | native IPoE | - | 538 | 7th to | | | | | 539 | 17:30 Mar. | | | | | 540 | 7th | | | | | 541 | ---------- | ------------ | ------------ | ------------- | ------ | 542 | 18:00 Mar. | 4RD/PPPoE | 4RD/IPoE on | native IPoE | rogue | 543 | 7th to | with closed | IEEE 11b | | | 544 | 5:00 Mar. | IPv6 | | | | 545 | 8th | | | | | 546 | ---------- | ------------ | ------------ | ------------- | ------ | 547 | 5:00 Mar. | dual stack | - | - | - | 548 | 8th to | (WIDE) | | | | 549 | 12:00 Mar. | | | | | 550 | 8th | | | | | 551 | ---------- | ------------ | ------------ | ------------- | ------ | 552 +------------+--------------+--------------+---------------+--------+ 553 Table 2: Time Slot of served networks through layer 2 mesh Wi-Fi 555 3.6. Settings for MTU and NAT / Firewall Traversal Tests for commercial 556 (P2P) Network Games 558 Evaluating MTU and NAT / Firewall Traversal Tests on each test 559 network for commercial (P2P) Network Games, Konami Digital 560 Entertainment (KDE) experiment team placed STUN [RFC5389] and TURN 561 [RFC5766] servers in the server segment of the camp core network. 562 KDE prepared test clients, for testing IPv4 NAT/Firewall traversal 563 from the view of consumer games. Test clients accessed to STUN / 564 TURN servers and evaluated whether each network satisfied 565 requirements from network games or not. The evaluation results will 566 be explained in section 4 of this document. 568 4. Experiences from the Experiments 570 4.1. User Survey by face-to-face interview 572 Here, we reports results of user survey. The user Survey was 573 conducted in face-to-face interview fashion. We interviewed 166 574 participants about brought devices and their OSes. We also asked 575 about the availability of networks, troubles or inconveniences. 577 Because implementations of 4RD, 464XLAT, SA46T were designed along 578 with performance specifications for home users, maximum users on each 579 implementation without heavy load were around 50 clients to 80 580 clients. Participants were likely to move another network when they 581 felt congestion or heavy load. Therefore, number of users on each 582 network was balanced to each other, around 50 to 80. 584 4.1.1. Client Profile 586 At the 2nd experiment, 297 unique devices were identified from 166 587 participants. This shows one participants brought two or more 588 devices. Typical participants took a normal personal computer and a 589 smart-phone or a similar personal device such as iPod touch, iPad, 590 Kindle, portable game devices. Table. Table 3 shows distributions 591 of Devices. Table. Table 4 shows distributions of OSes. We also 592 profiled applications on these devices. We looked over lots of 593 applications but some of them had problems due to lack of 594 applicability to IPv6 and its network characteristic. All 595 problematic cases were as same as reported in the 1st camp. The 596 worst case was that we saw an application was crashed. The lack of 597 applicability to IPv6 can be summarized as bellow. Any kind of VPN 598 has a propensity for getting into accidents. 600 +-------------------+--------------------------------+ 601 | Devices | # of participants (percentage) | 602 +-------------------+--------------------------------+ 603 | Personal Computer | 140 (47.1 %) | 604 | ----------------- | ------------------------------ | 605 | Tablet PC | 23 (7.7 %) | 606 | ----------------- | ------------------------------ | 607 | Smart Phone | 114 (38.4 %) | 608 | ----------------- | ------------------------------ | 609 | Game Devices | 19 (6.4 %) | 610 | ----------------- | ------------------------------ | 611 | Others | 1 (0.3 %) | 612 +-------------------+--------------------------------+ 614 Table 3: The distributions of devices of participants 616 +---------------------------+---------------------------+ 617 | OS | # of devices (percentage) | 618 +---------------------------+---------------------------+ 619 | Android | 37 (12.5 %) | 620 | ------------------------- | ------------------------- | 621 | Android 2.2 | 2 (9.7 %) | 622 | ------------------------- | ------------------------- | 623 | Android 2.3 | 3 (1.0 %) | 624 | ------------------------- | ------------------------- | 625 | Android 2.3.4 | 2 (0.7 %) | 626 | ------------------------- | ------------------------- | 627 | Android 4.0.2 | 1 (0.3 %) | 628 | ------------------------- | ------------------------- | 629 | Android 4.0.3 | 1 (0.3 %) | 630 | ------------------------- | ------------------------- | 631 | Arch Linux | 1 (0.3 %) | 632 | ------------------------- | ------------------------- | 633 | blackberry | 1 (0.3 %) | 634 | ------------------------- | ------------------------- | 635 | CentOS | 1 (0.3 %) | 636 | ------------------------- | ------------------------- | 637 | Debian | 1 (0.3 %) | 638 | ------------------------- | ------------------------- | 639 | FreeBSD | 1 (0.3 %) | 640 | ------------------------- | ------------------------- | 641 | iOS 4.3.2 JB | 1 (0.3 %) | 642 | ------------------------- | ------------------------- | 643 | iPad iOS | 21 (7.1 %) | 644 | ------------------------- | ------------------------- | 645 | iPhone iOS | 59 (19.9 %) | 646 | ------------------------- | ------------------------- | 647 | iPod Touch iOS | 11 (3.7 %) | 648 | ------------------------- | ------------------------- | 649 | Kindle | 1 (0.3 %) | 650 | ------------------------- | ------------------------- | 651 | Linux Open WRT 2.7.39 | 1 (0.3 %) | 652 | ------------------------- | ------------------------- | 653 | Mac OS X Lion | 48 (16.2 %) | 654 | ------------------------- | ------------------------- | 655 | Mac OS X Snow Leopard | 31 (10.4 %) | 656 | ------------------------- | ------------------------- | 657 | NetBSD 5.1 | 1 (0.3 %) | 658 | ------------------------- | ------------------------- | 659 | Nokia 5800 | 1 (0.3 %) | 660 | ------------------------- | ------------------------- | 661 | PSP | 2 (0.7 %) | 662 | ------------------------- | ------------------------- | 663 | PS Vita | 1 (0.3 %) | 664 | ------------------------- | ------------------------- | 665 | Ubuntu | 4 (1.3 %) | 666 | ------------------------- | ------------------------- | 667 | WiMAX Router | 1 (0.3 %) | 668 | ------------------------- | ------------------------- | 669 | Windows Vista | 4 (1.3 %) | 670 | ------------------------- | ------------------------- | 671 | Windows XP | 11 (3.7 %) | 672 | ------------------------- | ------------------------- | 673 | Windows 7 | 35 (11.8 %) | 674 | ------------------------- | ------------------------- | 675 | Windows Mobile | 3 (1.0 %) | 676 | ------------------------- | ------------------------- | 677 | Nintendo DS / 3DS (0.3 %) | 3 (1.0 %) | 678 +---------------------------+---------------------------+ 680 Table 4: The distributions of Operating Systems on participants' 681 devices 683 4.1.2. Reported Troubles 685 Here, we explain reported troubles or inconveniences of participants 686 on network connectivity. There troubles / inconveniences were 687 reported by participants through face-to-face interview or comments 688 on a wiki. 690 4.1.2.1. Failure of IPv6 neighbor discovery due to the on-link 691 assumption of IPv4 network 693 In the IPv6 single stack LAN, although 169.254/16 IPv4 Link Local 694 Address[RFC3927] was assigned to an interface, some devices tried to 695 get IPv4 address by DHCP4 and failed IPv6 neighbor discovery due to 696 the DHCP4 failure. In this case, the IPv6 network was never 697 available by the participant, therefore, they were likely to move to 698 another network where an IPv4 private/global address was assigned. 699 That is, IPv4 DHCP Discovery along with on-link assumption of IPv4 700 network blocked IPv6 Neighbor Discovery. 702 The similar harmful behavior on IPv6 Neighbor Discovery along with 703 on-link assumption in IPv4 only network has been described in 704 [RFC4943]. We need further evaluation and discussion on this IPv4 705 case. 707 4.1.2.2. Locked out IPv6 by vendor 709 There were two devices which were made different hardware but 710 equipped same OS with same version. These two devices were also 711 subscribed with a same mobile company and had a same behavior to the 712 IPv4. However, the one can get IPv6 address over WiFi network and 713 the other can not do so. The OS was announced that has IPv6 714 capability from the OS vendor. In this case, we suspected that the 715 hardware vendor may lock out IPv6 function. We should have further 716 examinations on this trouble. 718 4.1.2.3. Inappropriate selection of DNS resolvers 720 We observed inappropriate DNS resolver settings on resolve.conf of 721 several clients, for example, the DNS resolver address was never 722 reached from a client without translators. These inappropriate DNS 723 resolver settings were caused by careless mistake on DHCP6 and RA 724 settings due to lack of understanding on appropriate name servers on 725 a network. Once this trouble occurred, it was hard for users to 726 comprehend and to deal with it. If the ULA (Unique Local global 727 unicast Address [RFC4193]) was used, it might be getting more 728 complicated. 730 4.1.2.4. Previous configuration lived after moving to another WiFi 731 network 733 With some of latest OSes, participants had a trouble on network 734 configuration in the client PC. The trouble of network configuration 735 would be caused that the OS kept the previous network information and 736 could not renew after getting into another WiFi network. This 737 trouble was hard to be solved, when the trouble on mis-configuration 738 of name servers (section Section 4.1.2.3) occurred at the same time. 740 4.1.2.5. Crash of an application by plug-in 742 An IPv4 depended plugin crashed an application. Unawareness of dual 743 stack for application programmers may occur serious problems before 744 IPv6 deployment. It is more important to share what is dual stack 745 network and functions for dual stack communications. 747 4.1.2.6. Happy Eyeball implementation with turn-on/off switch 749 Happy eyeball implementation which enables faster communication with 750 IPv4 Internet is very effective if the IPv6 network is not available 751 or the IPv6 network becomes slow down than an IPv4 network. However, 752 when an IPv6 network is faster than an IPv4 network, the Happy 753 eyeball function may decrease the performance of web browsing. 754 Therefore, some implementations of Happy Eyeball equip turn-on/off 755 switch. 757 However, such turn-on/off switch usually requires parameter settings 758 and parameter settings are difficult. Actually, network engineers in 759 the 2nd experiment had difficulty on parameter tuning of Happy 760 Eyeball. Network engineers on the 2nd experiment worried about that 761 average or novice users could not use well current turn-on/off switch 762 implementation of Happy Eyeball. 764 4.1.2.7. Different behavior among OSes on MTU handling 766 In the 1st experiment, several participant claimed download of big 767 data did not work through PPTP access over SA46T. To verify the cause 768 of this problem, we evaluated communications to servers through PPTP 769 access over SA46T by Windows 7 and Mac OS Lion in this 2nd 770 experiment. Test servers were a CISCO UCS server to download remote 771 KVM java program and a linux server accessed by ssh. Then, the data 772 transfer on Windows 7 worked well both on access to the CISCO UCS 773 server and on the linux server. On the other hand, that on Mac OS 774 Lion stopped in a few minutes neither the CISCO UCS server nor on the 775 linux server. 777 To clarify that whether the difference derived from MTU size or not, 778 we evaluate ping program on each OS with changing payload size and DF 779 bit value. In Windows 7, ``ping -l 1500'' worked and ``ping -l 1500 780 -f'' did not work. On the other hand, in Mac OS Lion, ``ping -s '' 781 stopped around from 1411 to 1416. This result implies that MTU / 782 fragmentation handling between Windows 7 and Mac OS Lion are 783 different, and that MTU / fragmentation handling of Mac OS Lion may 784 not be suit to IPv4 / IPv6 transition situation. 786 We could not determine root cause of this trouble during the 2nd 787 experiment, because of SA46T fragment functions. Three SA46T 788 implementations were employed in 2nd experiment and they had 789 different packet fragmentation support shown in section Section 4.2. 790 Therefore, we could not remove the influence from lack of 791 fragmentation support of one of SA46T implementation. We have to 792 verify difference of behaviors on packet fragmentation among OSes 793 with further experiments. 795 4.2. MTU and NAT Traversal Tests for Network Games 797 Here, we explain the result of MTU and NAT Traversal Tests by KDE 798 experiment team. The test patterns were designed according to 799 [RFC4787] as follows; 801 o Address and Port Mapping Behavior 803 o Port Assignment Behavior 805 o Filtering Behavior 807 o Hairpinning Behavior 809 o Fragmentation of Outgoing Packets 811 o Receiving Fragmented Packets 813 These items were tested by KDE's test clients through STUN protocols 814 defined in [RFC5389] and in [RFC5780]. Clients sent UDP packets to 815 the STUN server along with test scenarios. 817 4.2.1. Between a Client and the STUN Server 819 Table Table 5 shows test items by a client. Table Table 6, Table 820 Table 7, Table Table 8 and Table Table 9 shows MTU and NAT Traversal 821 test results on each network. 823 The SA46T results in Table Table 8 and Table Table 9 derived from the 824 difference among implementations on fragment support function. 826 +------------------+------------------------------------------------+ 827 | Elements | Definition | 828 +------------------+------------------------------------------------+ 829 | NAT | Exist: NAT exists, - : no NAT | 830 | ---------------- | ---------------------------------------------- | 831 | Mapping | Good or Bad : Good / Bad Behavior for P2P Game | 832 | ---------------- | ---------------------------------------------- | 833 | Filtering | Good or Bad : Good / Bad Behavior for P2P Game | 834 | ---------------- | ---------------------------------------------- | 835 | RTT | Round Trip Time (msec.) | 836 | ---------------- | ---------------------------------------------- | 837 | MTU size from | size (byte) | 838 | client to server | | 839 | ---------------- | ---------------------------------------------- | 840 | Fragmentation | OK or NG : whether a big packet (DF=0) can be | 841 | from client to | sent from a client to the server with | 842 | server | fragmentation or not. | 843 | ---------------- | ---------------------------------------------- | 844 | MTU size from | size (byte) | 845 | server to client | | 846 | ---------------- | ---------------------------------------------- | 847 | Fragmentation | YES or NO : whether a big packet (DF=0) can be | 848 | from server to | sent from the server to a client with | 849 | client | fragmentation or not. | 850 +------------------+------------------------------------------------+ 852 Table 5: Test Elements of NAT, Mapping, Filtering ( RFC 4787 ) / RTT 853 / MTU 855 +-----------------+-------------------+------------------+ 856 | Elements | native PPPoE (v6) | native IPoE (v6) | 857 +-----------------+-------------------+------------------+ 858 | NAT | - | - | 859 | --------------- | ----------------- | ---------------- | 860 | Mapping | - | - | 861 | --------------- | ----------------- | ---------------- | 862 | Filtering | - | - | 863 | --------------- | ----------------- | ---------------- | 864 | RTT | 117 | 75 | 865 | --------------- | ----------------- | ---------------- | 866 | MTU size C => S | 1452 | 1500 | 867 | --------------- | ----------------- | ---------------- | 868 | Frag. C => S | YES | YES | 869 | --------------- | ----------------- | ---------------- | 870 | MTU size S => C | 1500 | 1500 | 871 | --------------- | ----------------- | ---------------- | 872 | Frag. S => C | YES | YES | 873 +-----------------+-------------------+------------------+ 875 Table 6: NAT Traversal Test Results between a Client and STUN Server 876 (global IPv6) 878 +-----------------+-------------------+------------------+ 879 | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | 880 +-----------------+-------------------+------------------+ 881 | NAT | Exist | Exist | 882 | --------------- | ----------------- | ---------------- | 883 | Mapping | Bad | Good | 884 | --------------- | ----------------- | ---------------- | 885 | Filtering | Good | Good | 886 | --------------- | ----------------- | ---------------- | 887 | RTT | 156 | 323 | 888 | --------------- | ----------------- | ---------------- | 889 | MTU size C => S | 1452 | 1452 | 890 | --------------- | ----------------- | ---------------- | 891 | Frag. C => S | NO | NO | 892 | --------------- | ----------------- | ---------------- | 893 | MTU size S => C | 1280 | 1452 | 894 | --------------- | ----------------- | ---------------- | 895 | Frag. S => C | YES | YES | 896 +-----------------+-------------------+------------------+ 898 Table 7: NAT Traversal Test Results between a Client and STUN Server 899 on 4RD 901 +-----------------+--------------------+-------------------+ 902 | Elements | 464XLAT/PPPoE (v4) | 464XLAT/IPoE (v4) | 903 +-----------------+--------------------+-------------------+ 904 | NAT | Exist | Exist | 905 | --------------- | ----------------- | ---------------- | 906 | Mapping | Good | Good | 907 | --------------- | ----------------- | ---------------- | 908 | Filtering | Good | Good | 909 | --------------- | ----------------- | ---------------- | 910 | RTT | 119 | 464 | 911 | --------------- | ----------------- | ---------------- | 912 | MTU size C => S | 1260 | 1476 | 913 | --------------- | ----------------- | ---------------- | 914 | Frag. C => S | YES | YES | 915 | --------------- | ----------------- | ---------------- | 916 | MTU size S => C | 1260 | 1480 | 917 | --------------- | ----------------- | ---------------- | 918 | Frag. S => C | YES | YES | 919 +-----------------+--------------------+-------------------+ 921 Table 8: NAT Traversal Test Results between a Client and STUN Server 922 on 464XLAT 924 +-----------------+------------------------+------------------------+ 925 | Elements | SA46T-FA (v4) | SA46T-FK (v4) | 926 +-----------------+------------------------+------------------------+ 927 | NAT | - | - | 928 | --------------- | ---------------------- | ---------------------- | 929 | Mapping | - | - | 930 | --------------- | ---------------------- | ---------------------- | 931 | Filtering | - | - | 932 | --------------- | ---------------------- | ---------------------- | 933 | RTT | 112 | 76 | 934 | --------------- | ---------------------- | ---------------------- | 935 | MTU size C => S | 1460 | 1460 | 936 | --------------- | ---------------------- | ---------------------- | 937 | Frag. C => S | YES | NO (lack of frag. | 938 | | | func. on SA46T-FK) | 939 | --------------- | ---------------------- | ---------------------- | 940 | MTU size S => C | NO (lack of frag. | NO (lack of frag. | 941 | | func. on SA46T-KO) | func. on SA46T-KO) | 942 | --------------- | ---------------------- | ---------------------- | 943 | Frag. S => C | NO (due to SA46T-KO) | NO (due to SA46T-KO) | 944 +-----------------+------------------------+------------------------+ 946 Table 9: NAT Traversal Test Results between a Client and STUN Server 947 on SA46T 949 4.2.2. Between Clients with NAT 951 +---------------+-------------+-------------------------------------+ 952 | Network | Protocol | Connectivity | 953 +---------------+-------------+-------------------------------------+ 954 | native PPPoE | IPv6 | Good (no NAT) | 955 | ----------- | ----------- | ----------- | 956 | native IPoE | IPv6 | Good (no NAT) | 957 | ----------- | ----------- | ----------------------------------- | 958 | 4RD/PPPoE | IPv4 | Bad (Address and Port dependent | 959 | | | mapping) | 960 | ----------- | ----------- | ----------------------------------- | 961 | 4RD/IPoE | IPv4 | Bad (no hairpinning) | 962 | ----------- | ----------- | ----------------------------------- | 963 | 464XLAT/PPPoE | IPv4 | Bad (no hairpinning) | 964 | ----------- | ----------- | ----------------------------------- | 965 | 464XLAT/IPoE | IPv4 | Bad (no hairpinning) | 966 | ----------- | ----------- | ----------------------------------- | 967 | SA46T-FA | IPv4 | Good (no NAT) | 968 | ----------- | ----------- | ----------------------------------- | 969 | SA46T-FK | IPv4 | Good (no NAT) | 970 +---------------+-------------+-------------------------------------+ 972 Table 10: P2P connectivity between Clients on each IPv6 or IPv4 973 network 975 4.3. Analysis of inappropriate authoritative servers from DNS64 Log 977 We analyzed DNS64 log to grasp inappropriate authoritative servers 978 for DNS64. DNS64 will fall back to A record query when an 979 authoritative server returns AAAA query with ``NOERROR ANSWER=0''. 980 DNS64 fails to fallback A record query when an authoritative server 981 returns inappropriate AAAA record mentioned in [RFC4074]. Also, 982 [RFC6147] says 984 Any other RCODE is treated as though the RCODE were 0 and the 985 answer section were empty. This is because of the large number of 986 different responses from deployed name servers when they receive 987 AAAA queries without a AAAA record being available. Note that 988 this means, for practical purposes, that several different classes 989 of error in the DNS are all treated as though a AAAA record is not 990 available for that owner name. 992 It is important to note that, as of this writing, some servers 993 respond with RCODE=3 to a AAAA query even if there is an A record 994 available for that owner name. Those servers are in clear 995 violation of the meaning of RCODE 3, and it is expected that they 996 will decline in use as IPv6 deployment increases. 998 In the 2nd experiment, we analyzed that distributions of error 999 messages of AAAA queries, and that whether number of error messages 1000 are changed by DNS implementations or not. 1002 The name server settings of the camp were as follows; 1004 F5 BIG-IP forwarded queries to DNS64 server except 1005 ``www.camp.wide.ad.jp''. 1007 DNS64 server only forwarded queries to Unbound/BIND resolver and 1008 did not do any iterative queries by itself 1010 We have changed target resolver from bind server to unbound server 1011 at midnight on March 5th 1013 We analyzed DNS64's error messages recorded in March 5th when DNS64 1014 forwarded queries to the BIND resolver. Table Table 11 shows number 1015 of unique authoritative servers in each error message. Most error 1016 messages of BIND resolver were FormError. Comparing differences 1017 between implementations, we recheck FormError authoritative servers 1018 by Unbound. The result is shown in Table Table 12. According to 1019 these result, BIND is more restrict to ``bogus'' response than 1020 Unbound. For example, BIND was denied about AAAA query for 1021 *.wikipedia.org, on the other hand, Unbound was allowed. Of course, 1022 we observed several web site URLs which both BIND and Unbound were 1023 denied on AAAA queries. 1025 Table Table 13 shows recheck result by both BIND and Unbound on all 1026 error messages of DNS64 during the camp (From March 5th to the end of 1027 closing of March 8th). Number of NXDOMAIN to AAAA, whose A record 1028 exist, was abnormal response that indicated failure of fallback to A 1029 query on DNS64. Such abnormal AAAA responses was returned to 69 1030 queries in Unbound case, 201 AAAA queries in BIND case. 1032 +-------------------+-----------------------------------+ 1033 | Error Type | # of unique authoritative servers | 1034 +-------------------+-----------------------------------+ 1035 | Refused | 47 | 1036 | ----------------- | ------------------------------ | 1037 | ServFail | 66 | 1038 | ----------------- | ------------------------------ | 1039 | FormError | 554 | 1040 +-------------------+-----------------------------------+ 1042 Table 11: The distributions of error messages 1044 +-----------------+-----------------------+-------------------------+ 1045 | Error Type | # of unique auth. | # of unique auth. | 1046 | | servers (BIND) | servers (Unbound) | 1047 +-----------------+-----------------------+-------------------------+ 1048 | NXDOMAIN | 449 | 21 | 1049 | --------- | --------- | --------- | 1050 | NOERROR Record | 66 | 506 | 1051 | = 0 | | | 1052 | --------- | --------- | --------- | 1053 | NOERROR Record | 9 | 7 | 1054 | > 0 | | | 1055 | --------- | --------- | --------- | 1056 | Others (ex. no | 11 | 20 | 1057 | reply) | | | 1058 +-----------------+-----------------------+-------------------------+ 1060 Table 12: Verification FormError of BIND by Unbound 1062 +-------------------------------------------------------+-----------+ 1063 | | number | 1064 +-------------------------------------------------------+-----------+ 1065 | # of names (A, AAAA, PTR, SRV( | 70886 | 1066 | --------- | --------- | 1067 | # of names queried by AAAA | 45633 | 1068 | --------- | --------- | 1069 | # of NXDOMAIN by AAAA from Unbound | 4011 | 1070 | --------- | --------- | 1071 | # of names which A record exist althogh an auth. | 69 | 1072 | server returned NXDOMAIN by AAAA from Unbound | | 1073 | # of NXDOMAIN by AAAA from Unbound | 4011 | 1074 | --------- | --------- | 1075 | # of NXDOMAIN by AAAA from BIND | 4234 | 1076 | --------- | --------- | 1077 | # of names which A record exist althogh an auth. | 201 | 1078 | server returned NXDOMAIN by AAAA from BIND | | 1079 +-------------------------------------------------------+-----------+ 1081 Table 13: Statistics of DNS through the camp 1083 5. Open Issues 1085 5.1. Dependency between IPv4 and IPv6 address configuration 1087 In this 2nd experiment, we observed troubles due to the dependency 1088 between IPv4 and IPv6 address configuration. We think, both IPv4 and 1089 IPv6 address configuration SHOULD work independently in a device or 1090 an OS. 1092 5.2. PMTUD, MTU mismatch problems and NAT behavior problems 1094 Through the 2nd experiment, we recognized that PMTUD, MTU mismatch 1095 problems may be caused not only from lack of fragment support of 1096 network devices but also difference among OSes' behaviors on MTU / 1097 packet size handling. Although we tested the difference between 1098 Windows 7 and Mac OS Lion on access to a linux server over PPTP 1099 through SA46T networks, we did not clarify the reason why Mac OS X 1100 Lion had MTU mismatch that Windows 7 did not face. PMTUD, MTU 1101 mismatch problems SHOULD be evaluated through further evaluation. 1103 KDE's evaluation results indicates that game applications need 1104 fragment support by network devices and/or OSes. KDE's evaluation 1105 results also implies that transition technologies which do not 1106 provide hairpinning behavior or and Endpoint Independent Mapping 1107 behavior through IPv6 backbones may not satisfy requirements from 1108 consumer game products. 1110 All members of the 2nd experiment team felt that PMTUD, MTU mismatch 1111 problems are quite serious, and that IETF working groups SHOULD 1112 reconsider PMTUD, MTU mismatch problems and SHOULD seek more 1113 practical solution on the current situation. 1115 5.3. Workaround for DNS64 problems 1117 As same as the 1st experiment, we met inappropriate DNS authoritative 1118 servers' behaviors on AAAA queries. Although the fundamental 1119 solution is requesting a correction to the administrator who manages 1120 such 'broken' authoritative server. Actually, Several DNS servers, 1121 which returned inappropriate AAAA replies on the 1st experiment, were 1122 fixed appropriately. The other work-around solutions that change the 1123 algorithm of DNS64 can be considered. 1125 5.3.1. Workaround for illegal NameError 1127 Even when the result of a query of AAAA record is RCODE 3, ask A 1128 record, and transform the result of A record to the AAAA record. 1129 Then, the AAAA record which is converted from A record is cached. 1130 This workaround makes additional queries when client sends a query 1131 for the name which has *no* records. Nevertheless, these results are 1132 cached, hence DNS64 server does not make extend queries too much. 1134 5.3.2. Workdaround for lame delegation 1136 When an authority server is not found (no servers specified as an 1137 authoritative server, or server doesn't return responses with AA 1138 bit), A record is asked without returning ServFail and the result of 1139 A record is transformed. The AAAA record which is converted from A 1140 record is cached same as section Section 5.3.1. Assuming If there is 1141 no authorized A record reply. DNS64 server sends ServFail to the 1142 client, and does not cache these records. Workaround B makes 1143 additional queries when client sends a query to the zone which has 1144 lame delegation. 1146 6. Conclusion and Future Work 1148 This experiment was the first time of WIDE Project on availability 1149 test of the IPv6 only connectivity with participants. Many 1150 participants replied good impressions, however, various issues were 1151 clarified through this experiment. We would like to store TIPS to 1152 operate the IPv6 only connectivity not only through the regular 1153 experiment on the WIDE camp, and also through the daily operation of 1154 the IPv6 only connectivity on the WIDE backbone. 1156 This experiment was the second trial on availability test of the IPv6 1157 only connectivity with participants by WIDE Project. Many 1158 participants replied good impressions, however, various issues were 1159 more clarified through this experiment. 1161 Through these two experiments, we aware that trouble shooting is very 1162 hard where multiple protocols are running. Experiment team prepared 1163 several testing tools, however, they were not enough to discover of 1164 causes of troubles. A standard method of trouble shooting in such 1165 network condition, criteria, and a touchstone program are needed. We 1166 continue to look out for the problematic cases and discuss among 1167 internet community for the best practice. 1169 7. Security Considerations 1171 As well as Arkko mentioned in [I-D.draft-arkko-ipv6-only-experience], 1172 the use of IPv6 instead of IPv4 by itself does not make a big 1173 security difference. In our experience, we only set up following 1174 security functions; the access control list on routers / servers, 1175 DNSSEC, accounting on the wireless network access. 1177 8. IANA Considerations 1179 This document has no IANA implications. 1181 9. References 1182 9.1. Normative References 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, March 1997. 1187 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1188 Translator (NAT) Terminology and Considerations", 1189 RFC 2663, August 1999. 1191 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1192 (DHCP) Service for IPv6", RFC 3736, April 2004. 1194 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1195 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1197 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1198 "IPv6 Router Advertisement Options for DNS Configuration", 1199 RFC 6106, November 2010. 1201 9.2. Informative References 1203 [I-D.draft-arkko-ipv6-only-experience] 1204 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 1205 Network", Febrary 2012, 1206 . 1208 [I-D.draft-ietf-v6ops-464xlat] 1209 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1210 Combination of Stateful and Stateless Translation", March 1211 2012, . 1213 [I-D.draft-matsuhira-sa46t-applicability] 1214 Matsuhira, N., "Applicability of Stateless automatic IPv4 1215 over IPv6 Tunneling (SA46T)", July 2011, 1216 . 1219 [I-D.draft-matsuhira-sa46t-as] 1220 Matsuhira, N., "Stateless Automatic IPv4 over IPv6 1221 Tunneling with IPv4 Address Sharing", April 2011, 1222 . 1224 [I-D.draft-matsuhira-sa46t-gaddr] 1225 Matsuhira, N., "Stateless Automatic IPv4 over IPv6 1226 Tunneling: Global SA46T Address Format", July 2011, 1227 . 1229 [I-D.draft-matsuhira-sa46t-mcast] 1230 Matsuhira, N., "SA46T Multicast Support", September 2011, 1231 . 1233 [I-D.draft-matsuhira-sa46t-motivation] 1234 Matsuhira, N., "Motivation for developing Stateless 1235 Automatic IPv4 over IPv6 Tunneling (SA46T)", July 2011, 1236 . 1238 [I-D.draft-matsuhira-sa46t-spec] 1239 Matsuhira, N., "Stateless Automatic IPv4 over IPv6 1240 Tunneling: Specification", January 2012, 1241 . 1243 [I-D.draft-murakami-softwire-4rd] 1244 Murakami, T., Troan, O., and S. Matsushima, "Stateless 1245 Automatic IPv4 over IPv6 Tunneling: Specification", 1246 September 2011, . 1249 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 1250 over Ethernet networks", STD 41, RFC 894, April 1984. 1252 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 1253 and R. Wheeler, "A Method for Transmitting PPP Over 1254 Ethernet (PPPoE)", RFC 2516, February 1999. 1256 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1257 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1258 May 2005. 1260 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 1261 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 1263 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1264 Addresses", RFC 4193, October 2005. 1266 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1267 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1268 RFC 4787, January 2007. 1270 [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor 1271 Discovery On-Link Assumption Considered Harmful", 1272 RFC 4943, September 2007. 1274 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1275 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1276 October 2008. 1278 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 1279 Relays around NAT (TURN): Relay Extensions to Session 1280 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 1282 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 1283 Using Session Traversal Utilities for NAT (STUN)", 1284 RFC 5780, May 2010. 1286 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1287 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1288 October 2010. 1290 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1291 IPv4/IPv6 Translation", RFC 6144, April 2011. 1293 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1294 Algorithm", RFC 6145, April 2011. 1296 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1297 NAT64: Network Address and Protocol Translation from IPv6 1298 Clients to IPv4 Servers", RFC 6146, April 2011. 1300 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 1301 Beijnum, "DNS64: DNS Extensions for Network Address 1302 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 1303 April 2011. 1305 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 1306 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 1308 [SEIL] Internet Initiative Japan, "SEIL", September 2011, 1309 . 1311 [YasudaAPRICOT2011] 1312 Yasuda, A., "Building for IPv6 by IPv6 Promotion Council 1313 Japan.", February, 2011, . 1317 Appendix A. Acknowledgments 1319 Here, we thank to all the participants of WIDE camp(s) on the 1320 experiments. We also say thank you to whom serving implementations 1321 and services in the Matsushiro Royal Hotel. 1323 N. Matsuhira of Fujitsu for SA46T. 1325 R. Nakamura of Keio Univ. for SA46T. 1327 H. Suenaga and K. Ooyatsu of IIJ for SEIL 4RD. 1329 JPIX and M. Kawashima of NEC AccessTechnica for 464XLAT. 1331 NTT-AT guys for providing BIG-IP and Pivot3, which does load 1332 balancing, DNS64, NAT64, and capturing all traffic. 1334 Y. Ueno of Keio Univ. for IPv6 L2TP implementation. 1336 R. Sato and M. Sato of Konami Digital Entertainment Co, Ltd. for NAT/ 1337 Firewall traversal testing. 1339 NTT EAST, Internet Multifeed, and IIJ for the commercial IPv6 1340 service. 1342 Authors' Addresses 1344 Hiroaki Hazeyama 1345 NAIST 1346 Takayama 8916-5 1347 Nara, 1348 Japan 1350 Phone: +81 743 72 5216 1351 Email: hiroa-ha@is.naist.jp 1353 Ruri Hiromi 1354 Intec Inc. 1355 1-3-3 Shin-Suna, Koutou 1356 Tokyo, 1357 Japan 1359 Email: hiromi@inetcore.com 1361 Tomohiro Ishihara 1362 Univ. of Tokyo 1363 3-8-1 Komaba, Meguro 1364 Tokyo, 1365 Japan 1367 Email: sho@c.u-tokyo.ac.jp 1368 Osamu Nakamura 1369 WIDE Project 1370 5322 Endo 1371 Kanagawa, 1372 Japan 1374 Email: osamu@wide.ad.jp