idnits 2.17.1 draft-hazeyama-widecamp-ipv6-only-experience-00.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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-arkko-ipv6-only-experience-03' is mentioned on line 692, but not defined ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) == Outdated reference: A later version (-05) exists of draft-arkko-ipv6-only-experience-03 == 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-03 == Outdated reference: A later version (-12) exists of draft-ietf-behave-ftp64-08 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). 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 Y. Ueno 5 Expires: April 26, 2012 Keio Univ. 6 October 24, 2011 8 Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011 9 draft-hazeyama-widecamp-ipv6-only-experience-00 11 Abstract 13 This document discusses our experiences from the IPv6 only network 14 experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The 15 WIDE camp Autumn 2011 was held from September 6th to September 9th, 16 2011, with 153 participants.This document reports answers of 17 questionnaire from participants, troubles and causes, with referring 18 IETF's IPv6 only network experiences. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 26, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4 57 3. Network and Experiment Setup . . . . . . . . . . . . . . . . . 5 58 3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 6 59 3.1.1. External Links . . . . . . . . . . . . . . . . . . . . 7 60 3.1.2. IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . 7 61 3.1.3. DHCP6 . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.4. DNS64 and NAT64 . . . . . . . . . . . . . . . . . . . 8 63 3.2. The IPv4 Networks . . . . . . . . . . . . . . . . . . . . 8 64 3.2.1. The IPv4 Network through SA46T . . . . . . . . . . . . 8 65 3.2.2. The IPv4 Network through 4RD . . . . . . . . . . . . . 8 66 4. Experiences from the Experiments . . . . . . . . . . . . . . . 9 67 4.1. Answers of Questionnaire . . . . . . . . . . . . . . . . . 9 68 4.1.1. The distributions of connectivities that 69 participants used . . . . . . . . . . . . . . . . . . 10 70 4.1.2. The satisfaction on the IPv6 only connectivity . . . . 10 71 4.1.3. The satisfaction on the network quality . . . . . . . 11 72 4.2. Reported Troubles . . . . . . . . . . . . . . . . . . . . 11 73 4.2.1. Troubles on the IPv6 capability of OSes and Devices . 11 74 4.2.1.1. Pains due to long fallback routine . . . . . . . . 12 75 4.2.1.2. Pains due to lack of DHCP6 capability . . . . . . 12 76 4.2.1.3. Pains due to the OS's incapability on IPv6 77 only setting . . . . . . . . . . . . . . . . . . . 12 78 4.2.1.4. Pains due to the device's incapability for IPv6 . 12 79 4.2.1.5. Failure of settings through GUI . . . . . . . . . 12 80 4.2.2. Troubles on Applications . . . . . . . . . . . . . . . 12 81 4.2.2.1. Pains due to IPv6 incapability on applications . . 13 82 4.2.2.2. Failures due to incapability of protocol 83 translation between IPv4 and IPv6 . . . . . . . . 13 84 4.2.2.3. Failures due to MTU mismatch problems . . . . . . 13 85 4.2.3. Troubles on Name Resolution . . . . . . . . . . . . . 13 86 4.2.3.1. Failures due to IPv4 address literals . . . . . . 14 87 4.2.3.2. Failures due to lack of reverse lookup entries 88 on AAAA records . . . . . . . . . . . . . . . . . 14 89 4.2.3.3. Failures due to the lame delegation . . . . . . . 14 90 4.2.3.4. Pains due to the overload of DNS64 . . . . . . . . 14 91 4.2.3.5. Failures due to inappropriate AAAA replies . . . . 15 92 5. Lessons from the experiences on the WIDE camp . . . . . . . . 15 93 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 94 6.1. PMTUD, MTU mismatch problems . . . . . . . . . . . . . . . 16 95 6.2. Inappropriate AAAA replies . . . . . . . . . . . . . . . . 16 97 7. Conclusion and Future Work . . . . . . . . . . . . . . . . . . 17 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 102 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 103 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 106 1. Introduction 108 This document discusses our experiences from the IPv6 only network 109 experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The 110 WIDE camp Autumn 2011 was held from September 6th to September 9th, 111 2011, with 153 participants. The main purposes of our experiment in 112 the WIDE camp were to grasp how much participants could live in the 113 IPv6 only connectivity environment, and to clarify what kind problems 114 would occurred on the operation through actual users' experiences of 115 the IPv6 only connectivity brought by DHCP6 [RFC3736] and the 6to4 116 translation by DNS64 and NAT64. This document reports answers of 117 questionnaire from 110 participants (71.9% of the whole 118 participants), troubles reported to the NOC team and causes that the 119 NOC team analyzed. Also, we refer to the IETF's IPv6 only network 120 experiences [I-D.draft-arkko-ipv6-only-experience], we try to clarify 121 new issues on IPv6 transition operation. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Technology and Terminology 131 In this document, the following terms are used. "NAT44" refers to 132 any IPv4-to-IPv4 network address translation algorithm, both "Basic 133 NAT" and "Network Address/Port Translator (NAPT)", as defined by 134 [RFC2663]. 136 "Dual Stack" refers to a technique for providing complete support for 137 both Internet protocols -- IPv4 and IPv6 -- in hosts and routers 138 [RFC4213]. 140 "NAT64" refers to a Network Address Translator - Protocol Translator 141 defined in [RFC6052], [I-D.ietf-behave-v6v4-framework], 142 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful], 143 [I-D.ietf-behave-dns64], [I-D.ietf-behave-ftp64]. 145 "SA46T" refers to Stateless Automatic IPv4 over IPv6 Tunneling 146 defined in [I-D.draft-matsuhira-sa46t-motivation], 147 [I-D.draft-matsuhira-sa46t-as], [I-D.draft-matsuhira-sa46t-spec], 148 [I-D.draft-matsuhira-sa46t-gaddr], 149 [I-D.draft-matsuhira-sa46t-applicability], 150 [I-D.draft-matsuhira-sa46t-mcast]. 152 "4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure 153 defined in [I-D.draft-murakami-softwire-4rd]. 155 3. Network and Experiment Setup 157 The WIDE camp autumn 2011 was held at Mastushiro Royal Hotel in 158 Nagano Prefecture of Japan from September 6th to September 9th, 2011. 159 We set up the IPv6 only network as the main conference network 160 connectivity. The conference network connectivity were mainly served 161 as wireless networks. The served IPv6 only network was not a pure 162 IPv6 only network because most participants had not IPv6 environment 163 on his / her organization, yet. Therefore, we served an IPv6 164 connectivity with 6to4 translation mechanisms, that is, with NAT64 165 and DNS64. 167 153 participants joined in the conference and tried the IPv6 only 168 connectivity through their own devices, such as Laptop PCs, smart 169 phones, and so on at September 6th and 7th, 2011. Participants 170 reported their experiences or troubles through questionnaire, emails, 171 and / or directly claims to the NOC team. 173 As a last resort for IPv4 only OSes or applications, we prepared a 174 global IPv4 network through SA46T. From the afternoon of September 175 7th 2011, we additionally provided a private IPv4 network through 176 4RD. 178 +--------+ +-----------+ 179 |SA46T-GW|--(v4)----+ |v6tunnel-gw| 180 | |--(v6)-+ | +-----------+ 181 +--------+ | | |(v6) |(v6) 182 +----------------------------------+ +---+ 183 +-----------| router |--(dual)--|DNS| 184 | +----------------------------------+ +---+ 185 | | |(v6) |(v4) 186 | | +--------+ 187 (v6) (dual) | NAT64 | 188 | | +--------+ 189 | +---------+ +---------------+ 190 | | WIDE BB |-(v4)-| IPv4 Internet | 191 | +---------+ +---------------+ 192 | |(v6) 193 | +---------------+ 194 | | IPv6 Internet | 195 +---------+ +---------------+ 196 |satellite| |(v6) 197 +---------+ +-------+ 198 | | ONU | 199 | +-------+ 200 | |(v6) 201 | +-------------+ 202 | | v6tunnel-gw | 203 | +-------------+ 204 | |(v6) 205 | +--------+ +-----+ 206 +-----------------| router |--(v6)--|DNS64| 207 +--------+ +-----+ 208 |(v6) | 209 +-----+ +--------+ | +-----+ 210 |DHCP4| |SA46T-GW| (v6) |DHCP6| 211 +-----+ +--------+ | +-----+ 212 |(v4) |(v4) | |(v6) 213 ----------------- user access ----------------- 215 The Basic Network Topology. 217 Figure 1 219 3.1. The IPv6-Only Network 221 Here, we explain the basic configurations on the IPv6-Only network on 222 the WIDE camp. 224 3.1.1. External Links 226 Figure. 1 shows the basic network topology of the WIDE camp autumn 227 2011. We announced the IPv6 and IPv4 addresses on the conference 228 network from the WIDE backbone's address block. The conference 229 network had two IPv6-Only external lines; one was an IPv6-Only 230 network through a portable satellite base station, the other was an 231 IPv6 Internet service on a FTTH line. 233 On the FTTH line, we set up an IPv6 tunnel between the hotel and Keio 234 university Shonan Fujisawa Campus (SFC). The main user access VLAN 235 was routed through this line, both the IPv6 network and the IPv4 236 network by SA46T. We tested two types of IPv6 services provided by 237 NTT East as an access carrier, Internet MultiFeed as a virtual 238 network enabler, and IIJ as an IPv6 ISP. The IPv6 network on the 239 FTTH external line was served through Native method 240 [YasudaAPRICOT2011]. From 2:00 PM of September 5th to 8:00 PM of 241 September 6th (JST), we used a Flet' s Hikari Next with IPv6 option. 242 The IPv6 address on the v6tunnel gateway were assigned from RA with 243 /64 prefix. From 8:00 PM of September 6th (JST), we changed the 244 setting of the external line service to a Flet's Hikari Next with 245 IPv6 option and a Hikari phone option, for the 4RD experiment, as 246 drawn in Figure 2. The differences brought by Hikari phone option 247 were as follows; i) an additional home gateway was added, ii) the 248 IPv6 address delegation method was changed from RA with /64 prefix 249 length to DHCP6[RFC3736] with /48 prefix length. 251 On the other hand, the satellite line directly connected between the 252 router on the hotel and the router on SFC. The satellite line 253 transferred another IPv6 network VLAN. 255 3.1.2. IPv6 Tunnel 257 For the IPv6 routing by WIDE Project's IPv6 address block, we 258 achieved an L2TP tunnel between the v6-tunnel gateway on the 259 Matsushiro and that on SFC over the FTTH line. The v6-tunnel 260 gateways were composed of Linux Debian squeeze (kernel 2.6.32) 261 servers with our original L2TP for IPv6 implementation. 263 3.1.3. DHCP6 265 Global IPv6 addresses for users and the DNS64 address were provided 266 through ISC's DHCP6 implementation [ISC-DHCP]. A user cloud 267 automatically get the IPv6 connectivity through the IPv6 Router 268 Advertisement Options for DNS Configuration[RFC6106], if the DHCP6 269 implementation on the user's device worked well. Otherwise, a user 270 had to set up DNS64 address as a resolver by manual. 272 3.1.4. DNS64 and NAT64 274 We used linuxnat64 [linuxnat64] as the NAT64 implementation. DNS64 275 was built by ISC bind 9.8-p4 [bind]. As shown in Figure 1, we placed 276 a DNS64 server on the hotel, on the other hand, NAT64 severs were 277 settled on SFC side. 279 3.2. The IPv4 Networks 281 3.2.1. The IPv4 Network through SA46T 283 As a last resort for IPv6 incapable OSes, devices and applications, 284 we prepared an global IPv4 network through SA46T. We used a software 285 implementation of SA46T developed by Fujitsu and Keio university. To 286 conduct the capability tests of NAT64, DNS64 and DHCP6, the global 287 IPv4 network was served as an option. A global IPv4 address was 288 assigned to a user's device by registering the device's MAC address 289 on a registration web page. We hid the registration web page from 290 participants until 1:00 PM of September 7th (JST) to pursue the 291 capability tests of NAT64, DNS64 and DHCP6. 293 3.2.2. The IPv4 Network through 4RD 295 We also held the capability test of 4RD implementations. On the 296 midnight of September 6th, we reconstructed the external link as 297 shown in Figure 2 to convey 4RD encapsulated packets. The 4RD-BR on 298 the SFC side was composed of a vyatta 4RD implementation 299 [vyatta-4RD]. On the hotel side, we used IIJ's SEIL 4RD 300 implementation [SEIL] as 4RD gateway and 4RD-BR and 4RD-CE. We 301 started the 4RD experiment to participants at 3:15 PM of September 302 7th (JST). The 4RD-CE provided a private IPv4 network by DHCP4 and 303 an IPv6 network by RA. The resolver was served through the DHCP4 304 function of the 4RD-CE. 306 +--------+ +-----------+ +---------+ 307 |SA46T-GW|--(v4)----+ |v6tunnel-gw| +---(v4)--| 4RD-BR | 308 | |--(v6)-+ | +-----------+ | +-(v6)--| (vyatta)| 309 +--------+ | | |(v6) |(v6) | | +---------+ 310 +----------------------------------+ +---+ 311 +-----------| router |--(dual)-|DNS| 312 | +----------------------------------+ +---+ 313 | | |(v6) |(v4) 314 | | +--------+ 315 (v6) (dual) | NAT64 | 316 | | +--------+ 317 | +---------+ +---------------+ 318 | | WIDE BB |-(v4)-| IPv4 Internet | 319 | +---------+ +---------------+ 320 | |(v6) 321 | +---------------+ 322 | | IPv6 Internet | 323 +---------+ +---------------+ 324 |satellite| |(v6) 325 +---------+ +-------+ +---+ +-------+ +------+ 326 | | ONU |-(v6)-|HGW|-(v6)-|4RD-BR |-(v6)-|4RD-CE| 327 | +-------+ +---+ |(SEIL) | |(SEIL)| 328 | +-------+ +------+ 329 | +-------------+ | | 330 | | v6tunnel-gw |--(v6)----+ ---user access--- 331 | +-------------+ (v6 / private v4) 332 | |(v6) 333 | +--------+ +-----+ 334 +-----------------| router |---(v6)---|DNS64| 335 +--------+ +-----+ 336 |(v6) | 337 +-----+ +--------+ | +-----+ 338 |DHCP4| |SA46T-GW| (v6) |DHCP6| 339 +-----+ +--------+ | +-----+ 340 |(v4) |(v4) | |(v6) 341 ----------------- user access ------------------- 343 The Network Topology with 4RD. 345 Figure 2 347 4. Experiences from the Experiments 349 4.1. Answers of Questionnaire 351 Here, we reports the answers of questionnaire about the experiments. 353 4.1.1. The distributions of connectivities that participants used 355 Table. 1 shows the distributions of used connectivities which 356 participants answered. 30 participants (19.6%) surely lived in the 357 IPv6 only connectivity with NAT64 / DNS64 during the all conference 358 days. 7 participants, who used the v6 connectivity and the v4 359 connectivity through SA46T, were such participants who came to the 360 NOC team in September 6th for the NOC team's help to be assigned the 361 IPv4 connectivity. 33 participants, who replied that he / she used 362 the IPv4 connectivity served by 4RD but did not use the IPv4 363 connectivity through SA46T, were such persons that needed the IPv4 364 connectivity but would not want to register his / her MAC address to 365 be registered. 34 participants, who used both SA46T and 4RD IPv4 366 connectivity, would join the comparison test between SA46T and 4RD. 368 +-------------------+--------------------------------+ 369 | Connectivities | # of participants (percentage) | 370 +-------------------+--------------------------------+ 371 | v6 only | 30 (19.6 %) | 372 | v6 only + SA46T | 7 (4.5 %) | 373 | v6 + 4RD | 33 (21.5 %) | 374 | v6 + SA46T + 4RD | 34 (22.2 %) | 375 | avoidance to ans. | 6 (3.9 %) | 376 | No response | 43 (28.1 %) | 377 +-------------------+--------------------------------+ 379 Table 1: The distributions of connectivities that participants used 381 4.1.2. The satisfaction on the IPv6 only connectivity 383 Table. 2 shows the satisfaction of participants about the IPv6 only 384 connectivity. Different from the expectation by the NOC team, 90 385 participants (58.8%) were satisfied in the IPv6 only connectivity. 386 Especially, Windows 7 users and Mac OS X 10.7 (Lion) users were 387 likely to reply good impressions because their DHCP6 functions worked 388 well. On the other hand, older OS users, Layer 3 VPN users (IPSec, 389 PPTP) and / or non-XMPP IM users were tend to escape into IPv4 390 connectivities. 392 From the free comments on questionnaire, many users were surprised 393 that the availability of the IPv6 only connectivity with NAT64 and 394 DNS64 were much more comfortable than that they thought. 396 +-------------------+--------------------------------+ 397 | Satisfaction | # of participants (percentage) | 398 +-------------------+--------------------------------+ 399 | Very Comfortable | 19 (12.4 %) | 400 | Comfortable | 52 (33.9 %) | 401 | Satisfactory | 20 (13.0 %) | 402 | Inconvenient | 13 (8.4 %) | 403 | Unbearable | 3 (1.9 %) | 404 | avoidance to ans. | 3 (1.9 %) | 405 | No response | 43 (28.1 %) | 406 +-------------------+--------------------------------+ 408 Table 2: The satisfaction on the IPv6 only connectivity 410 4.1.3. The satisfaction on the network quality 412 Table. 3 shows distributions of answers about the satisfaction on the 413 total network quality. 92 participants (60.1 %) were satisfied with 414 the quality on the conference network. Most of 15 participants, who 415 answered inconvenient or unbearable, were such participants who had 416 to log-in their companies or organizations' intranets through Layer 3 417 tunnels by IPv4 to read e-mails. 419 +-------------------+--------------------------------+ 420 | Satisfaction | # of participants (percentage) | 421 +-------------------+--------------------------------+ 422 | Very Comfortable | 14 (9.1 %) | 423 | Comfortable | 57 (37.2 %) | 424 | Satisfactory | 21 (13.7 %) | 425 | Inconvenient | 13 (8.4 %) | 426 | Unbearable | 2 (1.3 %) | 427 | avoidance to ans. | 3 (1.9 %) | 428 | No response | 43 (28.1 %) | 429 +-------------------+--------------------------------+ 431 Table 3: The quality on the network 433 4.2. Reported Troubles 435 Here, we summarize the reported troubles on the availability on the 436 IPv6 network and IPv4 networks through SA46T and 4RD. 438 4.2.1. Troubles on the IPv6 capability of OSes and Devices 440 Reported troubles on the IPv6 capability of OSes were as follows. 442 4.2.1.1. Pains due to long fallback routine 444 Most commercial OSes checked IPv4 connectivity when the IPv4 property 445 were enabled. The fallback routine spent a few minutes. Many 446 participants claimed why the initial network setting consumed a few 447 minutes and how to solve it. The long fall back routine was easily 448 solved by turning off the IPv4 property on each OS. The NOC team 449 provided several manuals for turning off / turning on the IPv4 450 property in several OSes. 452 4.2.1.2. Pains due to lack of DHCP6 capability 454 Older version OSes such as Mac OS X 10.6 (snow leopard) and older did 455 not have DHCP6 capability. Such users had to set up the DNS64 456 resolver address in manual. Several novice users were bothered with 457 setting up the DNS resolver settings and requested the NOC team 458 support to set up it. 460 4.2.1.3. Pains due to the OS's incapability on IPv6 only setting 462 Windows XP could not work without the IPv4 property, therefore, 463 Windows XP users had to set up a local proxy to resolve AAAA records 464 through IPv4 localhost IPv4 address (127.0.0.1). These settings were 465 difficult for most Windows XP users, many participants were tend to 466 give up the IPv6 settings. Several participants contributed TIPS or 467 setting instructions for such Windows XP users. 469 Android OS needed the IPv4 property on resolving names. 471 4.2.1.4. Pains due to the device's incapability for IPv6 473 Several devices, such as Apple's USB RJ45 Ethernet Port, did not have 474 the IPv6 capability. Also, some participant reported he had to 475 reinstall device drivers again and again. 477 4.2.1.5. Failure of settings through GUI 479 Some Mac Book Air user met the IPv6 settings disappeared in a few 480 minutes after he set the IPv6 settings through GUI. Also, Think Pad' 481 network setting manager could not set up IPv6 only setting through 482 GUI appropriately. These failure of settings could be solved by 483 setting through CLI commands. 485 4.2.2. Troubles on Applications 487 Three kinds of troubles on applications were reported to the NOC 488 team. 490 4.2.2.1. Pains due to IPv6 incapability on applications 492 As well as Arkko's report on IETF IPv6 only connectivity experiments 493 [I-D.draft-arkko-ipv6-only-experience], most non-XMPP based IM 494 applications and VoIP applications did not work. Skype and Window 495 live messenger users claimed to the NOC team that they wanted or had 496 to use such IMs in their business. 498 Several applications on Windows did not work, such as CVSNT, NOD32 499 signature updates. In Mac OS X, non-COCOA framework applications did 500 not work well. 502 On the other hand, Most HTTP/XMPP based applications or 503 communications were available or worked well, expect for such HTTP/ 504 XMPP based applications that might use IPv4 literals. 506 4.2.2.2. Failures due to incapability of protocol translation between 507 IPv4 and IPv6 509 IPSec-based applications, such as OpenVPN or Apple Mobile Me IPSec 510 and PKI based communications, did not work on the 6to4 connections. 511 PPTP clients did not work, too. Also, some FTP clients did not work 512 well on the v6 only connectivity with NAT64 / DNS64 and on the 4RD 513 IPv4 connectivity. 515 4.2.2.3. Failures due to MTU mismatch problems 517 During the setup on Sep. 5th, the NOC team met MTU problems. Several 518 servers were hosted on the cloud (KVM) environment on the WIDE 519 backbone (the WIDE Cloud). Basically, the WIDE Cloud backbone MTU 520 size was set 9000 for rapid live migration, however, MTU 9000 setting 521 on KVM hyper-visors collapsed various communications in the set up 522 day (Sep. 5th). Therefore, we set the MTU size of KVM hyper-visors 523 to 1500. 525 According to answers of questionnaire and reported troubles, various 526 UDP based communications, such as a Remote KVM function of CISCO UCS 527 server, did not still work well by MTU mismatch problems, not only on 528 the NAT64 / DNS64 environment, but also on the SA46T's 464 529 encapsulation. The NOC team could not find the actual MTU mismatch 530 points during the conference days. 532 4.2.3. Troubles on Name Resolution 534 The NOC team met several troubles on Name Resolution. Some of them 535 were derived from typical mis-configurations. 537 4.2.3.1. Failures due to IPv4 address literals 539 As well as Arkko's report on IETF IPv6 only connectivity experiments, 540 failures due to IPv4 address literals occurred. Many participants 541 claimed they could not access to their IPv4 servers by IPv4 address 542 literals through HTTP, SSH, VNC, IPSec, PPTP, IMAP, SMTP, and so on. 543 Some of them were fixed by changing IPv4 address literals to name 544 literals on the settings of their applications and / or by 545 registering their IPv4 servers in DNS records. However, most of 546 participants were not the administrators of their IPv4 servers or DNS 547 servers. Thus, most of them escaped to the IPv4 connectivity served 548 from the afternoon of Sep. 7th. 550 On the VNC, PPTP, IPSec and other VPN communications, many 551 participants claimed that several applications did not work well both 552 on IPv4 only servers and on IPv6 capable servers even when they 553 changed the access manners to name literals. Those access failures 554 might be affected by incapability for IPv6/IPv4 translation on VPN 555 protocols or MTU mismatch problems against UDP based communications. 557 4.2.3.2. Failures due to lack of reverse lookup entries on AAAA records 559 In the hot stage days, the NOC team detected several commercial web 560 pages could not be accessed due to failure of reverse lookup. 561 Therefore, we registered all reverse lookup AAAA records on the 562 camp.wide.ad.jp domains. 564 4.2.3.3. Failures due to the lame delegation 566 As mentioned above, some commercial web sites required the reverse 567 lookup in AAAA records as well as in A records. Several participants 568 claimed some commercial web pages cloud not be seen by failure of 569 reverse lookup, although we registered all reverse lookup entries in 570 AAAA about the camp.wide.ad.jp domain. We investigated the causes of 571 the failure of reverse lookup, the cause was the lame delegation on 572 the upper authoritative server of the DNS64 server (ns.wide.ad.jp) 573 brought by a mis-configuration of bind. After the lame delegation 574 was solved by an operator of ns.wide.ad.jp, problems on reverse 575 lookup were fixed. 577 4.2.3.4. Pains due to the overload of DNS64 579 In September 8th, the NOC team changed the configuration of DNS64 to 580 enable DNSSEC functions. After enabling DNSSEC, the DNS64 server, 581 which was placed on a KVM virtual machine on the Matsushiro Royal 582 hotel, was overwhelmed by handling many queries and key 583 verifications. Then, participants hardly accessed to IPv4 Internet 584 with DNS64. 586 Therefore, the NOC team moved the DNS64 server from the KVM 587 environment to a physical server, then, the overload on the DNS64 588 server was solved. 590 4.2.3.5. Failures due to inappropriate AAAA replies 592 Different from the IETF's experiment, the accessibility test of web 593 pages were conducted by manual, that is, by actual web access of 594 participants. Some web pages, especially search result pages of 595 travel reservation sites, could not access from the IPv6 network 596 through NAT64 / DNS64 translation. The reasons why connections to 597 such web pages failed were derived from inappropriate DNS replies 598 mentioned in [RFC4074]. 600 We observed ``Return Name Error'' mentioned in Section 4.2 of 601 [RFC4074], ``Return Other Erroneous Codes'' in Section 4.3 of 602 [RFC4074], and Return a Broken Response in Section 4.4 [RFC4074], 603 respectively. We could not solve these problems in the conference 604 days because these problems were derived from wrong behaviors of DNS 605 resolvers on the web sites. 607 5. Lessons from the experiences on the WIDE camp 609 Here, we describe lessons or recommendations from the experiences on 610 the WIDE camp for building or living in an IPv6 environment with 611 NAT64 and DNS64. 613 o You SHOULD implement or enable the IPv6 capability into your site 614 soon if it is possible, because NAT or NAPT environments might 615 cause various problems such as MTU mismatch, low throughput, 616 incapability on translation, and so on. Actually, some partner 617 organizations of the WIDE project requested IPv6 address blocks 618 soon after the WIDE camp. 620 o You SHOULD update or purchase OSes on your computers to the latest 621 version, because Window 7 users and Mac OS X 10.7 (Lion) users did 622 not meet critical troubles, and because older OS users met various 623 troubles. 625 o You WOULD be better to register reverse AAAA lookup entries, 626 because several commercial web sites require the reverse lookup. 628 o You SHOULD give sufficient resources to a DNS64 server, because 629 the failure or overload of DNS64 server are critical for the 630 accessibility to IPv4 Internet from IPv6 only network. 632 o You SHOULD check whether your web / DNS appliances return 633 inappropriate AAAA replies or not, because some web appliances 634 might return inappropriate AAAA replies and inappropriate AAAA 635 replies can be solved by only administrators on web sites. 637 o You SHOULD take care of MTU size on multiple overlaid underlay 638 networks because PMTUD might not work in some times. 640 6. Open Issues 642 6.1. PMTUD, MTU mismatch problems 644 On the camp-net experiments, PMTUD, MTU mismatch problems occurred in 645 several points. The NOC team and experiment team could not 646 completely fix all MTU mismatch problems, therefore, several 647 participants could not use UDP communications, such as a remote KVM 648 function of a CISCO UCS server, through the conference network or VPN 649 tunnels. 651 These problems were mainly derived from the failure of Path MTU 652 Discovery. In the operational problem to avoid the overload of 653 routers or DDoS attacks, man y networks turn off PMTUD functions on 654 routers. However, many applications or implementations of tunneling 655 / encapsulation protocols assume that the PMTUD would work. 657 6.2. Inappropriate AAAA replies 659 Inappropriate DNS replies pointed in [RFC4074] are one of open issues 660 on the IPv6 transitions. Ideally, vendors SHOULD implement web / DNS 661 appliances with taking care of [RFC4074] and network operators SHOULD 662 replace all AAAA resolvers to appropriate AAAA resolvers. However, 663 such solution will spend money, human resources, and time to 664 deployment. A possible immediate solution is changing the fallback 665 routines of DNS64 resolvers as follows; 667 o A DNS64 resolver resolves the A record even when a DNS reply 668 contained NXDOMAIN or ServFail. 670 o A DNS64 resolver caches all possible A records. When a DNS reply 671 was NOERROR, the DNS64 resolver queries the AAAA record. If the 672 AAAA record exists, then the DNS64 resolver returns the AAAA 673 record to a client, and if not, the DNS64 resolver returns the 674 cached A record to the client. 676 These solutions would be required further discussion in appropriate 677 working group. 679 7. Conclusion and Future Work 681 This experiment was the first time of WIDE Project on availability 682 test of the IPv6 only connectivity with participants. Many 683 participants replied good impressions, however, various issues were 684 clarified through this experiment. We would like to store TIPS to 685 operate the IPv6 only connectivity not only through the regular 686 experiment on the WIDE camp, and also through the daily operation of 687 the IPv6 only connectivity on the WIDE backbone. 689 8. Security Considerations 691 As well as Arkko mentioned in 692 [I-D.draft-arkko-ipv6-only-experience-03], the use of IPv6 instead of 693 IPv4 by itself does not make a big security difference. In our 694 experience, we only set up following security functions; the access 695 control list on routers / servers, DNSSEC, accounting on the wireless 696 network access. 698 9. IANA Considerations 700 This document has no IANA implications. 702 10. References 704 10.1. Normative References 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, March 1997. 709 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 710 Translator (NAT) Terminology and Considerations", 711 RFC 2663, August 1999. 713 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 714 (DHCP) Service for IPv6", RFC 3736, April 2004. 716 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 717 for IPv6 Hosts and Routers", RFC 4213, October 2005. 719 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 720 "IPv6 Router Advertisement Options for DNS Configuration", 721 RFC 6106, November 2010. 723 10.2. Informative References 725 [I-D.draft-arkko-ipv6-only-experience] 726 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 727 Network", April 2011, . 730 [I-D.draft-matsuhira-sa46t-applicability] 731 Matsuhira, N., "Applicability of Stateless automatic IPv4 732 over IPv6 Tunneling (SA46T)", July 2011, 733 . 736 [I-D.draft-matsuhira-sa46t-as] 737 Matsuhira, N., "Stateless Automatic IPv4 over IPv6 738 Tunneling with IPv4 Address Sharing", April 2011, 739 . 741 [I-D.draft-matsuhira-sa46t-gaddr] 742 Matsuhira, N., "Stateless Automatic IPv4 over IPv6 743 Tunneling: Global SA46T Address Format", July 2011, 744 . 746 [I-D.draft-matsuhira-sa46t-mcast] 747 Matsuhira, N., "SA46T Multicast Support", September 2011, 748 . 750 [I-D.draft-matsuhira-sa46t-motivation] 751 Matsuhira, N., "Motivation for developing Stateless 752 Automatic IPv4 over IPv6 Tunneling (SA46T)", July 2011, 753 . 755 [I-D.draft-matsuhira-sa46t-spec] 756 Matsuhira, N., "Stateless Automatic IPv4 over IPv6 757 Tunneling: Specification", July 2011, 758 . 760 [I-D.draft-murakami-softwire-4rd] 761 Murakami, T., Troan, O., and S. Matsushima, "Stateless 762 Automatic IPv4 over IPv6 Tunneling: Specification", 763 September 2011, . 766 [I-D.ietf-behave-dns64] 767 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 768 "DNS64: DNS extensions for Network Address Translation 769 from IPv6 Clients to IPv4 Servers", October 2010, 770 . 772 [I-D.ietf-behave-ftp64] 773 Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", 774 March 2011, . 777 [I-D.ietf-behave-v6v4-framework] 778 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 779 IPv4/IPv6 Translation", August 2010, 780 . 782 [I-D.ietf-behave-v6v4-xlate] 783 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 784 Algorithm", September 2010, 785 . 787 [I-D.ietf-behave-v6v4-xlate-stateful] 788 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 789 NAT64: Network Address and Protocol Translation from IPv6 790 Clients to IPv4 Servers", July 2010, 791 . 794 [ISC-DHCP] 795 Internet Systems Consortium., "DHCP", 796 . 798 [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against 799 DNS Queries for IPv6 Addresses", RFC 4074, May 2005. 801 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 802 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 803 October 2010. 805 [SEIL] Internet Initiative Japan, "SEIL", September 2011, 806 . 808 [YasudaAPRICOT2011] 809 Yasuda, A., "Building for IPv6 by IPv6 Promotion Council 810 Japan.", February, 2011, . 814 [bind] Internet Systems Consortium., "BIND", 815 . 817 [linuxnat64] 818 Geeknet, Inc., "Linux NAT64 implementation", 819 . 821 [vyatta-4RD] 822 masakazu, "masakazu's weblog (In Japanese)", June 2011, 823 . 825 Appendix A. Acknowledgements 827 Here, we thank to 153 participants of WIDE camp 2011 autumn on this 828 experiments. We also say thank you to N. Matsuhira of Fujitsu for 829 the SA46T implemnetation, H. Suenaga and K. Ooyatsu of IIJ for SEIL 830 4RD implementation, NTT EAST, Internet Multifeed, and IIJ for serving 831 the commercial IPv6 Internet service for this experiment on the 832 Matsushiro Royal Hotel. 834 Authors' Addresses 836 Hiroaki Hazeyama 837 NAIST 838 Takayama 8916-5 839 Nara, 840 Japan 842 Phone: +81 743 72 5216 843 Email: hiroa-ha@is.naist.jp 845 Yukito Ueno 846 Keio Univ. 847 5322 Endo 848 Kanagawa, 849 Japan 851 Email: eden@sfc.wide.ad.jp