[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                        H. Hazeyama
Internet-Draft                                                     NAIST
Intended status: Informational                                   Y. Ueno
Expires: April 26, 2012                                       Keio Univ.
                                                        October 24, 2011


   Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011
            draft-hazeyama-widecamp-ipv6-only-experience-00

Abstract

   This document discusses our experiences from the IPv6 only network
   experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011.  The
   WIDE camp Autumn 2011 was held from September 6th to September 9th,
   2011, with 153 participants.This document reports answers of
   questionnaire from participants, troubles and causes, with referring
   IETF's IPv6 only network experiences.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 26, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Hazeyama & Ueno          Expires April 26, 2012                 [Page 1]


Internet-Draft              Abbreviated Title               October 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Technology and Terminology . . . . . . . . . . . . . . . . . .  4
   3.  Network and Experiment Setup . . . . . . . . . . . . . . . . .  5
     3.1.  The IPv6-Only Network  . . . . . . . . . . . . . . . . . .  6
       3.1.1.  External Links . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  IPv6 Tunnel  . . . . . . . . . . . . . . . . . . . . .  7
       3.1.3.  DHCP6  . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.4.  DNS64 and NAT64  . . . . . . . . . . . . . . . . . . .  8
     3.2.  The IPv4 Networks  . . . . . . . . . . . . . . . . . . . .  8
       3.2.1.  The IPv4 Network through SA46T . . . . . . . . . . . .  8
       3.2.2.  The IPv4 Network through 4RD . . . . . . . . . . . . .  8
   4.  Experiences from the Experiments . . . . . . . . . . . . . . .  9
     4.1.  Answers of Questionnaire . . . . . . . . . . . . . . . . .  9
       4.1.1.  The distributions of connectivities that
               participants used  . . . . . . . . . . . . . . . . . . 10
       4.1.2.  The satisfaction on the IPv6 only connectivity . . . . 10
       4.1.3.  The satisfaction on the network quality  . . . . . . . 11
     4.2.  Reported Troubles  . . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  Troubles on the IPv6 capability of OSes and Devices  . 11
         4.2.1.1.  Pains due to long fallback routine . . . . . . . . 12
         4.2.1.2.  Pains due to lack of DHCP6 capability  . . . . . . 12
         4.2.1.3.  Pains due to the OS's incapability on IPv6
                   only setting . . . . . . . . . . . . . . . . . . . 12
         4.2.1.4.  Pains due to the device's incapability for IPv6  . 12
         4.2.1.5.  Failure of settings through GUI  . . . . . . . . . 12
       4.2.2.  Troubles on Applications . . . . . . . . . . . . . . . 12
         4.2.2.1.  Pains due to IPv6 incapability on applications . . 13
         4.2.2.2.  Failures due to incapability of protocol
                   translation between IPv4 and IPv6  . . . . . . . . 13
         4.2.2.3.  Failures due to MTU mismatch problems  . . . . . . 13
       4.2.3.  Troubles on Name Resolution  . . . . . . . . . . . . . 13
         4.2.3.1.  Failures due to IPv4 address literals  . . . . . . 14
         4.2.3.2.  Failures due to lack of reverse lookup entries
                   on AAAA records  . . . . . . . . . . . . . . . . . 14
         4.2.3.3.  Failures due to the lame delegation  . . . . . . . 14
         4.2.3.4.  Pains due to the overload of DNS64 . . . . . . . . 14
         4.2.3.5.  Failures due to inappropriate AAAA replies . . . . 15
   5.  Lessons from the experiences on the WIDE camp  . . . . . . . . 15
   6.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  PMTUD, MTU mismatch problems . . . . . . . . . . . . . . . 16
     6.2.  Inappropriate AAAA replies . . . . . . . . . . . . . . . . 16



Hazeyama & Ueno          Expires April 26, 2012                 [Page 2]


Internet-Draft              Abbreviated Title               October 2011


   7.  Conclusion and Future Work . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20











































Hazeyama & Ueno          Expires April 26, 2012                 [Page 3]


Internet-Draft              Abbreviated Title               October 2011


1.  Introduction

   This document discusses our experiences from the IPv6 only network
   experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011.  The
   WIDE camp Autumn 2011 was held from September 6th to September 9th,
   2011, with 153 participants.  The main purposes of our experiment in
   the WIDE camp were to grasp how much participants could live in the
   IPv6 only connectivity environment, and to clarify what kind problems
   would occurred on the operation through actual users' experiences of
   the IPv6 only connectivity brought by DHCP6 [RFC3736] and the 6to4
   translation by DNS64 and NAT64.  This document reports answers of
   questionnaire from 110 participants (71.9% of the whole
   participants), troubles reported to the NOC team and causes that the
   NOC team analyzed.  Also, we refer to the IETF's IPv6 only network
   experiences [I-D.draft-arkko-ipv6-only-experience], we try to clarify
   new issues on IPv6 transition operation.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Technology and Terminology

   In this document, the following terms are used.  "NAT44" refers to
   any IPv4-to-IPv4 network address translation algorithm, both "Basic
   NAT" and "Network Address/Port Translator (NAPT)", as defined by
   [RFC2663].

   "Dual Stack" refers to a technique for providing complete support for
   both Internet protocols -- IPv4 and IPv6 -- in hosts and routers
   [RFC4213].

   "NAT64" refers to a Network Address Translator - Protocol Translator
   defined in [RFC6052], [I-D.ietf-behave-v6v4-framework],
   [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful],
   [I-D.ietf-behave-dns64], [I-D.ietf-behave-ftp64].

   "SA46T" refers to Stateless Automatic IPv4 over IPv6 Tunneling
   defined in [I-D.draft-matsuhira-sa46t-motivation],
   [I-D.draft-matsuhira-sa46t-as], [I-D.draft-matsuhira-sa46t-spec],
   [I-D.draft-matsuhira-sa46t-gaddr],
   [I-D.draft-matsuhira-sa46t-applicability],
   [I-D.draft-matsuhira-sa46t-mcast].

   "4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure



Hazeyama & Ueno          Expires April 26, 2012                 [Page 4]


Internet-Draft              Abbreviated Title               October 2011


   defined in [I-D.draft-murakami-softwire-4rd].


3.  Network and Experiment Setup

   The WIDE camp autumn 2011 was held at Mastushiro Royal Hotel in
   Nagano Prefecture of Japan from September 6th to September 9th, 2011.
   We set up the IPv6 only network as the main conference network
   connectivity.  The conference network connectivity were mainly served
   as wireless networks.  The served IPv6 only network was not a pure
   IPv6 only network because most participants had not IPv6 environment
   on his / her organization, yet.  Therefore, we served an IPv6
   connectivity with 6to4 translation mechanisms, that is, with NAT64
   and DNS64.

   153 participants joined in the conference and tried the IPv6 only
   connectivity through their own devices, such as Laptop PCs, smart
   phones, and so on at September 6th and 7th, 2011.  Participants
   reported their experiences or troubles through questionnaire, emails,
   and / or directly claims to the NOC team.

   As a last resort for IPv4 only OSes or applications, we prepared a
   global IPv4 network through SA46T. From the afternoon of September
   7th 2011, we additionally provided a private IPv4 network through
   4RD.


























Hazeyama & Ueno          Expires April 26, 2012                 [Page 5]


Internet-Draft              Abbreviated Title               October 2011


       +--------+              +-----------+
       |SA46T-GW|--(v4)----+   |v6tunnel-gw|
       |        |--(v6)-+  |   +-----------+
       +--------+       |  |     |(v6)  |(v6)
                    +----------------------------------+          +---+
        +-----------|              router              |--(dual)--|DNS|
        |           +----------------------------------+          +---+
        |                   |             |(v6) |(v4)
        |                   |            +--------+
       (v6)              (dual)          |  NAT64 |
        |                   |            +--------+
        |               +---------+      +---------------+
        |               | WIDE BB |-(v4)-| IPv4 Internet |
        |               +---------+      +---------------+
        |                     |(v6)
        |              +---------------+
        |              | IPv6 Internet |
    +---------+        +---------------+
    |satellite|               |(v6)
    +---------+           +-------+
        |                 |  ONU  |
        |                 +-------+
        |                     |(v6)
        |               +-------------+
        |               | v6tunnel-gw |
        |               +-------------+
        |                     |(v6)
        |                 +--------+        +-----+
        +-----------------| router |--(v6)--|DNS64|
                          +--------+        +-----+
                           |(v6) |
     +-----+        +--------+   |       +-----+
     |DHCP4|        |SA46T-GW|  (v6)     |DHCP6|
     +-----+        +--------+   |       +-----+
        |(v4)              |(v4) |          |(v6)
      ----------------- user access -----------------

                        The Basic Network Topology.

                                 Figure 1

3.1.  The IPv6-Only Network

   Here, we explain the basic configurations on the IPv6-Only network on
   the WIDE camp.






Hazeyama & Ueno          Expires April 26, 2012                 [Page 6]


Internet-Draft              Abbreviated Title               October 2011


3.1.1.  External Links

   Figure. 1 shows the basic network topology of the WIDE camp autumn
   2011.  We announced the IPv6 and IPv4 addresses on the conference
   network from the WIDE backbone's address block.  The conference
   network had two IPv6-Only external lines; one was an IPv6-Only
   network through a portable satellite base station, the other was an
   IPv6 Internet service on a FTTH line.

   On the FTTH line, we set up an IPv6 tunnel between the hotel and Keio
   university Shonan Fujisawa Campus (SFC).  The main user access VLAN
   was routed through this line, both the IPv6 network and the IPv4
   network by SA46T. We tested two types of IPv6 services provided by
   NTT East as an access carrier, Internet MultiFeed as a virtual
   network enabler, and IIJ as an IPv6 ISP.  The IPv6 network on the
   FTTH external line was served through Native method
   [YasudaAPRICOT2011].  From 2:00 PM of September 5th to 8:00 PM of
   September 6th (JST), we used a Flet' s Hikari Next with IPv6 option.
   The IPv6 address on the v6tunnel gateway were assigned from RA with
   /64 prefix.  From 8:00 PM of September 6th (JST), we changed the
   setting of the external line service to a Flet's Hikari Next with
   IPv6 option and a Hikari phone option, for the 4RD experiment, as
   drawn in Figure 2.  The differences brought by Hikari phone option
   were as follows; i) an additional home gateway was added, ii) the
   IPv6 address delegation method was changed from RA with /64 prefix
   length to DHCP6[RFC3736] with /48 prefix length.

   On the other hand, the satellite line directly connected between the
   router on the hotel and the router on SFC.  The satellite line
   transferred another IPv6 network VLAN.

3.1.2.  IPv6 Tunnel

   For the IPv6 routing by WIDE Project's IPv6 address block, we
   achieved an L2TP tunnel between the v6-tunnel gateway on the
   Matsushiro and that on SFC over the FTTH line.  The v6-tunnel
   gateways were composed of Linux Debian squeeze (kernel 2.6.32)
   servers with our original L2TP for IPv6 implementation.

3.1.3.  DHCP6

   Global IPv6 addresses for users and the DNS64 address were provided
   through ISC's DHCP6 implementation [ISC-DHCP].  A user cloud
   automatically get the IPv6 connectivity through the IPv6 Router
   Advertisement Options for DNS Configuration[RFC6106], if the DHCP6
   implementation on the user's device worked well.  Otherwise, a user
   had to set up DNS64 address as a resolver by manual.




Hazeyama & Ueno          Expires April 26, 2012                 [Page 7]


Internet-Draft              Abbreviated Title               October 2011


3.1.4.  DNS64 and NAT64

   We used linuxnat64 [linuxnat64] as the NAT64 implementation.  DNS64
   was built by ISC bind 9.8-p4 [bind].  As shown in Figure 1, we placed
   a DNS64 server on the hotel, on the other hand, NAT64 severs were
   settled on SFC side.

3.2.  The IPv4 Networks

3.2.1.  The IPv4 Network through SA46T

   As a last resort for IPv6 incapable OSes, devices and applications,
   we prepared an global IPv4 network through SA46T. We used a software
   implementation of SA46T developed by Fujitsu and Keio university.  To
   conduct the capability tests of NAT64, DNS64 and DHCP6, the global
   IPv4 network was served as an option.  A global IPv4 address was
   assigned to a user's device by registering the device's MAC address
   on a registration web page.  We hid the registration web page from
   participants until 1:00 PM of September 7th (JST) to pursue the
   capability tests of NAT64, DNS64 and DHCP6.

3.2.2.  The IPv4 Network through 4RD

   We also held the capability test of 4RD implementations.  On the
   midnight of September 6th, we reconstructed the external link as
   shown in Figure 2 to convey 4RD encapsulated packets.  The 4RD-BR on
   the SFC side was composed of a vyatta 4RD implementation
   [vyatta-4RD].  On the hotel side, we used IIJ's SEIL 4RD
   implementation [SEIL] as 4RD gateway and 4RD-BR and 4RD-CE.  We
   started the 4RD experiment to participants at 3:15 PM of September
   7th (JST).  The 4RD-CE provided a private IPv4 network by DHCP4 and
   an IPv6 network by RA.  The resolver was served through the DHCP4
   function of the 4RD-CE.


















Hazeyama & Ueno          Expires April 26, 2012                 [Page 8]


Internet-Draft              Abbreviated Title               October 2011


       +--------+              +-----------+               +---------+
       |SA46T-GW|--(v4)----+   |v6tunnel-gw|     +---(v4)--| 4RD-BR  |
       |        |--(v6)-+  |   +-----------+     | +-(v6)--| (vyatta)|
       +--------+       |  |     |(v6)  |(v6)    | |       +---------+
                    +----------------------------------+         +---+
        +-----------|              router              |--(dual)-|DNS|
        |           +----------------------------------+         +---+
        |                   |             |(v6) |(v4)
        |                   |            +--------+
       (v6)              (dual)          |  NAT64 |
        |                   |            +--------+
        |               +---------+      +---------------+
        |               | WIDE BB |-(v4)-| IPv4 Internet |
        |               +---------+      +---------------+
        |                     |(v6)
        |              +---------------+
        |              | IPv6 Internet |
    +---------+        +---------------+
    |satellite|          |(v6)
    +---------+      +-------+      +---+      +-------+      +------+
        |            |  ONU  |-(v6)-|HGW|-(v6)-|4RD-BR |-(v6)-|4RD-CE|
        |            +-------+      +---+      |(SEIL) |      |(SEIL)|
        |                                      +-------+      +------+
        |               +-------------+          |                |
        |               | v6tunnel-gw |--(v6)----+    ---user access---
        |               +-------------+               (v6 / private v4)
        |                     |(v6)
        |                 +--------+          +-----+
        +-----------------| router |---(v6)---|DNS64|
                          +--------+          +-----+
                           |(v6) |
     +-----+        +--------+   |       +-----+
     |DHCP4|        |SA46T-GW|  (v6)     |DHCP6|
     +-----+        +--------+   |       +-----+
        |(v4)              |(v4) |          |(v6)
      ----------------- user access -------------------

                      The Network Topology with 4RD.

                                 Figure 2


4.  Experiences from the Experiments

4.1.  Answers of Questionnaire

   Here, we reports the answers of questionnaire about the experiments.




Hazeyama & Ueno          Expires April 26, 2012                 [Page 9]


Internet-Draft              Abbreviated Title               October 2011


4.1.1.  The distributions of connectivities that participants used

   Table. 1 shows the distributions of used connectivities which
   participants answered. 30 participants (19.6%) surely lived in the
   IPv6 only connectivity with NAT64 / DNS64 during the all conference
   days. 7 participants, who used the v6 connectivity and the v4
   connectivity through SA46T, were such participants who came to the
   NOC team in September 6th for the NOC team's help to be assigned the
   IPv4 connectivity. 33 participants, who replied that he / she used
   the IPv4 connectivity served by 4RD but did not use the IPv4
   connectivity through SA46T, were such persons that needed the IPv4
   connectivity but would not want to register his / her MAC address to
   be registered. 34 participants, who used both SA46T and 4RD IPv4
   connectivity, would join the comparison test between SA46T and 4RD.

          +-------------------+--------------------------------+
          |   Connectivities  | # of participants (percentage) |
          +-------------------+--------------------------------+
          |      v6 only      |           30 (19.6 %)          |
          |  v6 only + SA46T  |            7 (4.5 %)           |
          |      v6 + 4RD     |           33 (21.5 %)          |
          |  v6 + SA46T + 4RD |           34 (22.2 %)          |
          | avoidance to ans. |            6 (3.9 %)           |
          |    No response    |           43 (28.1 %)          |
          +-------------------+--------------------------------+

    Table 1: The distributions of connectivities that participants used

4.1.2.  The satisfaction on the IPv6 only connectivity

   Table. 2 shows the satisfaction of participants about the IPv6 only
   connectivity.  Different from the expectation by the NOC team, 90
   participants (58.8%) were satisfied in the IPv6 only connectivity.
   Especially, Windows 7 users and Mac OS X 10.7 (Lion) users were
   likely to reply good impressions because their DHCP6 functions worked
   well.  On the other hand, older OS users, Layer 3 VPN users (IPSec,
   PPTP) and / or non-XMPP IM users were tend to escape into IPv4
   connectivities.

   From the free comments on questionnaire, many users were surprised
   that the availability of the IPv6 only connectivity with NAT64 and
   DNS64 were much more comfortable than that they thought.









Hazeyama & Ueno          Expires April 26, 2012                [Page 10]


Internet-Draft              Abbreviated Title               October 2011


          +-------------------+--------------------------------+
          |    Satisfaction   | # of participants (percentage) |
          +-------------------+--------------------------------+
          |  Very Comfortable |           19 (12.4 %)          |
          |    Comfortable    |           52 (33.9 %)          |
          |    Satisfactory   |           20 (13.0 %)          |
          |    Inconvenient   |           13 (8.4 %)           |
          |     Unbearable    |            3 (1.9 %)           |
          | avoidance to ans. |            3 (1.9 %)           |
          |    No response    |           43 (28.1 %)          |
          +-------------------+--------------------------------+

          Table 2: The satisfaction on the IPv6 only connectivity

4.1.3.  The satisfaction on the network quality

   Table. 3 shows distributions of answers about the satisfaction on the
   total network quality. 92 participants (60.1 %) were satisfied with
   the quality on the conference network.  Most of 15 participants, who
   answered inconvenient or unbearable, were such participants who had
   to log-in their companies or organizations' intranets through Layer 3
   tunnels by IPv4 to read e-mails.

          +-------------------+--------------------------------+
          |    Satisfaction   | # of participants (percentage) |
          +-------------------+--------------------------------+
          |  Very Comfortable |           14 (9.1 %)           |
          |    Comfortable    |           57 (37.2 %)          |
          |    Satisfactory   |           21 (13.7 %)          |
          |    Inconvenient   |           13 (8.4 %)           |
          |     Unbearable    |            2 (1.3 %)           |
          | avoidance to ans. |            3 (1.9 %)           |
          |    No response    |           43 (28.1 %)          |
          +-------------------+--------------------------------+

                    Table 3: The quality on the network

4.2.  Reported Troubles

   Here, we summarize the reported troubles on the availability on the
   IPv6 network and IPv4 networks through SA46T and 4RD.

4.2.1.  Troubles on the IPv6 capability of OSes and Devices

   Reported troubles on the IPv6 capability of OSes were as follows.






Hazeyama & Ueno          Expires April 26, 2012                [Page 11]


Internet-Draft              Abbreviated Title               October 2011


4.2.1.1.  Pains due to long fallback routine

   Most commercial OSes checked IPv4 connectivity when the IPv4 property
   were enabled.  The fallback routine spent a few minutes.  Many
   participants claimed why the initial network setting consumed a few
   minutes and how to solve it.  The long fall back routine was easily
   solved by turning off the IPv4 property on each OS.  The NOC team
   provided several manuals for turning off / turning on the IPv4
   property in several OSes.

4.2.1.2.  Pains due to lack of DHCP6 capability

   Older version OSes such as Mac OS X 10.6 (snow leopard) and older did
   not have DHCP6 capability.  Such users had to set up the DNS64
   resolver address in manual.  Several novice users were bothered with
   setting up the DNS resolver settings and requested the NOC team
   support to set up it.

4.2.1.3.  Pains due to the OS's incapability on IPv6 only setting

   Windows XP could not work without the IPv4 property, therefore,
   Windows XP users had to set up a local proxy to resolve AAAA records
   through IPv4 localhost IPv4 address (127.0.0.1).  These settings were
   difficult for most Windows XP users, many participants were tend to
   give up the IPv6 settings.  Several participants contributed TIPS or
   setting instructions for such Windows XP users.

   Android OS needed the IPv4 property on resolving names.

4.2.1.4.  Pains due to the device's incapability for IPv6

   Several devices, such as Apple's USB RJ45 Ethernet Port, did not have
   the IPv6 capability.  Also, some participant reported he had to
   reinstall device drivers again and again.

4.2.1.5.  Failure of settings through GUI

   Some Mac Book Air user met the IPv6 settings disappeared in a few
   minutes after he set the IPv6 settings through GUI.  Also, Think Pad'
   network setting manager could not set up IPv6 only setting through
   GUI appropriately.  These failure of settings could be solved by
   setting through CLI commands.

4.2.2.  Troubles on Applications

   Three kinds of troubles on applications were reported to the NOC
   team.




Hazeyama & Ueno          Expires April 26, 2012                [Page 12]


Internet-Draft              Abbreviated Title               October 2011


4.2.2.1.  Pains due to IPv6 incapability on applications

   As well as Arkko's report on IETF IPv6 only connectivity experiments
   [I-D.draft-arkko-ipv6-only-experience], most non-XMPP based IM
   applications and VoIP applications did not work.  Skype and Window
   live messenger users claimed to the NOC team that they wanted or had
   to use such IMs in their business.

   Several applications on Windows did not work, such as CVSNT, NOD32
   signature updates.  In Mac OS X, non-COCOA framework applications did
   not work well.

   On the other hand, Most HTTP/XMPP based applications or
   communications were available or worked well, expect for such HTTP/
   XMPP based applications that might use IPv4 literals.

4.2.2.2.  Failures due to incapability of protocol translation between
          IPv4 and IPv6

   IPSec-based applications, such as OpenVPN or Apple Mobile Me IPSec
   and PKI based communications, did not work on the 6to4 connections.
   PPTP clients did not work, too.  Also, some FTP clients did not work
   well on the v6 only connectivity with NAT64 / DNS64 and on the 4RD
   IPv4 connectivity.

4.2.2.3.  Failures due to MTU mismatch problems

   During the setup on Sep. 5th, the NOC team met MTU problems.  Several
   servers were hosted on the cloud (KVM) environment on the WIDE
   backbone (the WIDE Cloud).  Basically, the WIDE Cloud backbone MTU
   size was set 9000 for rapid live migration, however, MTU 9000 setting
   on KVM hyper-visors collapsed various communications in the set up
   day (Sep. 5th).  Therefore, we set the MTU size of KVM hyper-visors
   to 1500.

   According to answers of questionnaire and reported troubles, various
   UDP based communications, such as a Remote KVM function of CISCO UCS
   server, did not still work well by MTU mismatch problems, not only on
   the NAT64 / DNS64 environment, but also on the SA46T's 464
   encapsulation.  The NOC team could not find the actual MTU mismatch
   points during the conference days.

4.2.3.  Troubles on Name Resolution

   The NOC team met several troubles on Name Resolution.  Some of them
   were derived from typical mis-configurations.





Hazeyama & Ueno          Expires April 26, 2012                [Page 13]


Internet-Draft              Abbreviated Title               October 2011


4.2.3.1.  Failures due to IPv4 address literals

   As well as Arkko's report on IETF IPv6 only connectivity experiments,
   failures due to IPv4 address literals occurred.  Many participants
   claimed they could not access to their IPv4 servers by IPv4 address
   literals through HTTP, SSH, VNC, IPSec, PPTP, IMAP, SMTP, and so on.
   Some of them were fixed by changing IPv4 address literals to name
   literals on the settings of their applications and / or by
   registering their IPv4 servers in DNS records.  However, most of
   participants were not the administrators of their IPv4 servers or DNS
   servers.  Thus, most of them escaped to the IPv4 connectivity served
   from the afternoon of Sep. 7th.

   On the VNC, PPTP, IPSec and other VPN communications, many
   participants claimed that several applications did not work well both
   on IPv4 only servers and on IPv6 capable servers even when they
   changed the access manners to name literals.  Those access failures
   might be affected by incapability for IPv6/IPv4 translation on VPN
   protocols or MTU mismatch problems against UDP based communications.

4.2.3.2.  Failures due to lack of reverse lookup entries on AAAA records

   In the hot stage days, the NOC team detected several commercial web
   pages could not be accessed due to failure of reverse lookup.
   Therefore, we registered all reverse lookup AAAA records on the
   camp.wide.ad.jp domains.

4.2.3.3.  Failures due to the lame delegation

   As mentioned above, some commercial web sites required the reverse
   lookup in AAAA records as well as in A records.  Several participants
   claimed some commercial web pages cloud not be seen by failure of
   reverse lookup, although we registered all reverse lookup entries in
   AAAA about the camp.wide.ad.jp domain.  We investigated the causes of
   the failure of reverse lookup, the cause was the lame delegation on
   the upper authoritative server of the DNS64 server (ns.wide.ad.jp)
   brought by a mis-configuration of bind.  After the lame delegation
   was solved by an operator of ns.wide.ad.jp, problems on reverse
   lookup were fixed.

4.2.3.4.  Pains due to the overload of DNS64

   In September 8th, the NOC team changed the configuration of DNS64 to
   enable DNSSEC functions.  After enabling DNSSEC, the DNS64 server,
   which was placed on a KVM virtual machine on the Matsushiro Royal
   hotel, was overwhelmed by handling many queries and key
   verifications.  Then, participants hardly accessed to IPv4 Internet
   with DNS64.



Hazeyama & Ueno          Expires April 26, 2012                [Page 14]


Internet-Draft              Abbreviated Title               October 2011


   Therefore, the NOC team moved the DNS64 server from the KVM
   environment to a physical server, then, the overload on the DNS64
   server was solved.

4.2.3.5.  Failures due to inappropriate AAAA replies

   Different from the IETF's experiment, the accessibility test of web
   pages were conducted by manual, that is, by actual web access of
   participants.  Some web pages, especially search result pages of
   travel reservation sites, could not access from the IPv6 network
   through NAT64 / DNS64 translation.  The reasons why connections to
   such web pages failed were derived from inappropriate DNS replies
   mentioned in [RFC4074].

   We observed ``Return Name Error'' mentioned in Section 4.2 of
   [RFC4074], ``Return Other Erroneous Codes'' in Section 4.3 of
   [RFC4074], and Return a Broken Response in Section 4.4 [RFC4074],
   respectively.  We could not solve these problems in the conference
   days because these problems were derived from wrong behaviors of DNS
   resolvers on the web sites.


5.  Lessons from the experiences on the WIDE camp

   Here, we describe lessons or recommendations from the experiences on
   the WIDE camp for building or living in an IPv6 environment with
   NAT64 and DNS64.

   o  You SHOULD implement or enable the IPv6 capability into your site
      soon if it is possible, because NAT or NAPT environments might
      cause various problems such as MTU mismatch, low throughput,
      incapability on translation, and so on.  Actually, some partner
      organizations of the WIDE project requested IPv6 address blocks
      soon after the WIDE camp.

   o  You SHOULD update or purchase OSes on your computers to the latest
      version, because Window 7 users and Mac OS X 10.7 (Lion) users did
      not meet critical troubles, and because older OS users met various
      troubles.

   o  You WOULD be better to register reverse AAAA lookup entries,
      because several commercial web sites require the reverse lookup.

   o  You SHOULD give sufficient resources to a DNS64 server, because
      the failure or overload of DNS64 server are critical for the
      accessibility to IPv4 Internet from IPv6 only network.





Hazeyama & Ueno          Expires April 26, 2012                [Page 15]


Internet-Draft              Abbreviated Title               October 2011


   o  You SHOULD check whether your web / DNS appliances return
      inappropriate AAAA replies or not, because some web appliances
      might return inappropriate AAAA replies and inappropriate AAAA
      replies can be solved by only administrators on web sites.

   o  You SHOULD take care of MTU size on multiple overlaid underlay
      networks because PMTUD might not work in some times.


6.  Open Issues

6.1.  PMTUD, MTU mismatch problems

   On the camp-net experiments, PMTUD, MTU mismatch problems occurred in
   several points.  The NOC team and experiment team could not
   completely fix all MTU mismatch problems, therefore, several
   participants could not use UDP communications, such as a remote KVM
   function of a CISCO UCS server, through the conference network or VPN
   tunnels.

   These problems were mainly derived from the failure of Path MTU
   Discovery.  In the operational problem to avoid the overload of
   routers or DDoS attacks, man y networks turn off PMTUD functions on
   routers.  However, many applications or implementations of tunneling
   / encapsulation protocols assume that the PMTUD would work.

6.2.  Inappropriate AAAA replies

   Inappropriate DNS replies pointed in [RFC4074] are one of open issues
   on the IPv6 transitions.  Ideally, vendors SHOULD implement web / DNS
   appliances with taking care of [RFC4074] and network operators SHOULD
   replace all AAAA resolvers to appropriate AAAA resolvers.  However,
   such solution will spend money, human resources, and time to
   deployment.  A possible immediate solution is changing the fallback
   routines of DNS64 resolvers as follows;

   o  A DNS64 resolver resolves the A record even when a DNS reply
      contained NXDOMAIN or ServFail.

   o  A DNS64 resolver caches all possible A records.  When a DNS reply
      was NOERROR, the DNS64 resolver queries the AAAA record.  If the
      AAAA record exists, then the DNS64 resolver returns the AAAA
      record to a client, and if not, the DNS64 resolver returns the
      cached A record to the client.

   These solutions would be required further discussion in appropriate
   working group.




Hazeyama & Ueno          Expires April 26, 2012                [Page 16]


Internet-Draft              Abbreviated Title               October 2011


7.  Conclusion and Future Work

   This experiment was the first time of WIDE Project on availability
   test of the IPv6 only connectivity with participants.  Many
   participants replied good impressions, however, various issues were
   clarified through this experiment.  We would like to store TIPS to
   operate the IPv6 only connectivity not only through the regular
   experiment on the WIDE camp, and also through the daily operation of
   the IPv6 only connectivity on the WIDE backbone.


8.  Security Considerations

   As well as Arkko mentioned in
   [I-D.draft-arkko-ipv6-only-experience-03], the use of IPv6 instead of
   IPv4 by itself does not make a big security difference.  In our
   experience, we only set up following security functions; the access
   control list on routers / servers, DNSSEC, accounting on the wireless
   network access.


9.  IANA Considerations

   This document has no IANA implications.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3736]  Droms, R., "Stateless Dynamic Host Configuration Protocol
              (DHCP) Service for IPv6", RFC 3736, April 2004.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC6106]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
              "IPv6 Router Advertisement Options for DNS Configuration",
              RFC 6106, November 2010.





Hazeyama & Ueno          Expires April 26, 2012                [Page 17]


Internet-Draft              Abbreviated Title               October 2011


10.2.  Informative References

   [I-D.draft-arkko-ipv6-only-experience]
              Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", April 2011, <draft-arkko-ipv6-only-experience-03
              (work in progress)>.

   [I-D.draft-matsuhira-sa46t-applicability]
              Matsuhira, N., "Applicability of Stateless automatic IPv4
              over IPv6 Tunneling (SA46T)", July 2011,
              <draft-matsuhira-sa46t-applicability-02 (work in
              progress)>.

   [I-D.draft-matsuhira-sa46t-as]
              Matsuhira, N., "Stateless Automatic IPv4 over IPv6
              Tunneling with IPv4 Address Sharing", April 2011,
              <draft-matsuhira-sa46t-as-01 (work in progress)>.

   [I-D.draft-matsuhira-sa46t-gaddr]
              Matsuhira, N., "Stateless Automatic IPv4 over IPv6
              Tunneling: Global SA46T Address Format", July 2011,
              <draft-matsuhira-sa46t-gaddr-03 (work in progress)>.

   [I-D.draft-matsuhira-sa46t-mcast]
              Matsuhira, N., "SA46T Multicast Support", September 2011,
              <draft-matsuhira-sa46t-mcast-00 (work in progress)>.

   [I-D.draft-matsuhira-sa46t-motivation]
              Matsuhira, N., "Motivation for developing Stateless
              Automatic IPv4 over IPv6 Tunneling (SA46T)", July 2011,
              <draft-matsuhira-sa46t-motivation-00 (work in progress)>.

   [I-D.draft-matsuhira-sa46t-spec]
              Matsuhira, N., "Stateless Automatic IPv4 over IPv6
              Tunneling: Specification", July 2011,
              <draft-matsuhira-sa46t-spec-03 (work in progress)>.

   [I-D.draft-murakami-softwire-4rd]
              Murakami, T., Troan, O., and S. Matsushima, "Stateless
              Automatic IPv4 over IPv6 Tunneling: Specification",
              September 2011, <draft-murakami-softwire-4rd-01 (work in
              progress)>.

   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to IPv4 Servers", October 2010,
              <draft-ietf-behave-dns64-11 (work in progress)>.



Hazeyama & Ueno          Expires April 26, 2012                [Page 18]


Internet-Draft              Abbreviated Title               October 2011


   [I-D.ietf-behave-ftp64]
              Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
              March 2011, <draft-ietf-behave-ftp64-08 (work in
              progress)>.

   [I-D.ietf-behave-v6v4-framework]
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", August 2010,
              <draft-ietf-behave-v6v4-framework-10 (work in progress)>.

   [I-D.ietf-behave-v6v4-xlate]
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", September 2010,
              <draft-ietf-behave-v6v4-xlate-23 (work in progress)>.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", July 2010,
              <draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress)>.

   [ISC-DHCP]
              Internet Systems Consortium., "DHCP",
              <http://www.isc.org/software/dhcp>.

   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [SEIL]     Internet Initiative Japan, "SEIL", September 2011,
              <http://www.seil.jp/>.

   [YasudaAPRICOT2011]
              Yasuda, A., "Building for IPv6 by IPv6 Promotion Council
              Japan.", February, 2011, <http://meetings.apnic.net/
              __data/assets/pdf_file/0003/30981/
              Ayumu-Yasuda-apricot.pdf>.

   [bind]     Internet Systems Consortium., "BIND",
              <http://www.isc.org/software/bind>.

   [linuxnat64]
              Geeknet, Inc., "Linux NAT64 implementation",
              <http://linuxnat64.sourceforge.net/>.



Hazeyama & Ueno          Expires April 26, 2012                [Page 19]


Internet-Draft              Abbreviated Title               October 2011


   [vyatta-4RD]
              masakazu, "masakazu's weblog (In Japanese)", June 2011,
              <http://bougaidenpa.org/masakazu/archives/176>.


Appendix A.  Acknowledgements

   Here, we thank to 153 participants of WIDE camp 2011 autumn on this
   experiments.  We also say thank you to N. Matsuhira of Fujitsu for
   the SA46T implemnetation, H. Suenaga and K. Ooyatsu of IIJ for SEIL
   4RD implementation, NTT EAST, Internet Multifeed, and IIJ for serving
   the commercial IPv6 Internet service for this experiment on the
   Matsushiro Royal Hotel.


Authors' Addresses

   Hiroaki Hazeyama
   NAIST
   Takayama 8916-5
   Nara,
   Japan

   Phone: +81 743 72 5216
   Email: hiroa-ha@is.naist.jp


   Yukito Ueno
   Keio Univ.
   5322 Endo
   Kanagawa,
   Japan

   Email: eden@sfc.wide.ad.jp

















Hazeyama & Ueno          Expires April 26, 2012                [Page 20]


Html markup produced by rfcmarkup 1.118, available from https://tools.ietf.org/tools/rfcmarkup/