Internet DRAFT - draft-hazeyama-widecamp-ipv6-only-experience

draft-hazeyama-widecamp-ipv6-only-experience






Network Working Group                                        H. Hazeyama
Internet-Draft                                                     NAIST
Intended status: Informational                                 R. Hiromi
Expires: April 6, 2013                                        Intec Inc.
                                                             T. Ishihara
                                                          Univ. of Tokyo
                                                             O. Nakamura
                                                            WIDE Project
                                                         October 3, 2012


Experiences from IPv6-Only Networks with Transition Technologies in the
                         WIDE Camp Autumn 2012
            draft-hazeyama-widecamp-ipv6-only-experience-02

Abstract

   This document reports and discusses issues on IPv6 only networks and
   IPv4/IPv6 transition technologies through our experiences on the 3rd
   experiment on the WIDE camp.  The 3rd experiment was held from
   September 3rd to September 6th, 2012.  As well as past two
   experiments, we conducted face to face interview to participants for
   grasping IPv6 capability on users' devices, OSes, and applications.
   In addition to this, we explored solutions to mitigate timeout /
   fallback problems of IPv4/IPv6 dual stack clients on an IPv6 only
   network that is composed of DHCP6 and DNS64/NAT64.

Status of this Memo

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

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

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

   This Internet-Draft will expire on April 6, 2013.

Copyright Notice

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



Hazeyama, et al.          Expires April 6, 2013                 [Page 1]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


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










































Hazeyama, et al.          Expires April 6, 2013                 [Page 2]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  History of ``Live with IPv6 experiments'' on the WIDE
           camp . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Summary of the 1st experiment  . . . . . . . . . . . .  4
       1.1.2.  Summary of the 2nd experiment  . . . . . . . . . . . .  4
     1.2.  Abstract of the 3rd experiment . . . . . . . . . . . . . .  6
     1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  7
   2.  Technology and Terminology . . . . . . . . . . . . . . . . . .  7
   3.  Basic configuration of Network and Experiments . . . . . . . .  8
   4.  Experiments  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  An Experiment in RA method . . . . . . . . . . . . . . . . 11
       4.1.1.  Details of Network Configuration . . . . . . . . . . . 11
       4.1.2.  User Survey  . . . . . . . . . . . . . . . . . . . . . 12
         4.1.2.1.  Client Profile . . . . . . . . . . . . . . . . . . 12
         4.1.2.2.  Behaviors of DHCP6 Clients . . . . . . . . . . . . 13
         4.1.2.3.  Timeout / Fallback Problems  . . . . . . . . . . . 14
     4.2.  Experiments in DHCP-PD method  . . . . . . . . . . . . . . 14
       4.2.1.  Basic Network Configuration  . . . . . . . . . . . . . 14
       4.2.2.  Experiment 0 . . . . . . . . . . . . . . . . . . . . . 15
         4.2.2.1.  Waiting timeout of DHCP4 in Windows 7  . . . . . . 16
         4.2.2.2.  Long TCP fallback in Mac OS X Lion and
                   Mountain Lion  . . . . . . . . . . . . . . . . . . 16
         4.2.2.3.  Incompletion of network settings in iOS 5  . . . . 16
         4.2.2.4.  Incapability of IPv6 DNS settings by DHCP6 . . . . 16
       4.2.3.  Experiment 1 . . . . . . . . . . . . . . . . . . . . . 17
         4.2.3.1.  Diff of network settings . . . . . . . . . . . . . 17
         4.2.3.2.  Result . . . . . . . . . . . . . . . . . . . . . . 18
       4.2.4.  Experiment 2 . . . . . . . . . . . . . . . . . . . . . 19
         4.2.4.1.  Diff of network settings . . . . . . . . . . . . . 19
         4.2.4.2.  Result . . . . . . . . . . . . . . . . . . . . . . 21
       4.2.5.  Experiment 3 . . . . . . . . . . . . . . . . . . . . . 21
         4.2.5.1.  Diff of network settings . . . . . . . . . . . . . 21
         4.2.5.2.  Result . . . . . . . . . . . . . . . . . . . . . . 22
   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27








Hazeyama, et al.          Expires April 6, 2013                 [Page 3]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


1.  Introduction

   This document reports and discusses issues on IPv6 only networks and
   IPv4/IPv6 transition technologies through our experiences on the 3rd
   experiment on the WIDE camp.  The 3rd experiment was held from
   September 3rd to September 6th in Matsushiro Royal Hotel, Nagano,
   Japan, where is the same hotel of the 1st and 2nd experiments.

1.1.  History of ``Live with IPv6 experiments'' on the WIDE camp

   "Live with IPv6 experiment" aims to evaluate commercial IPv6 network
   services, the availability of IPv6 networks with several IPv4 / IPv6
   translation / encapsulation technologies by actual users'
   experiences, and to grasp issues on IPv4 exhaustion situation or IPv4
   / IPv6 transition.  These experiments are based on an assumption that
   ISP backbone networks will be constructed on IPv6 only and end
   customer will have to use an IPv6 network with 64 translators or an
   IPv4 network with 464 translators to keep current usage of the
   Internet services.

1.1.1.  Summary of the 1st experiment

   The 1st experiment was held in Matsushiro Royal Hotel from September
   6th to September 9th, 2011 with 153 participants, and the experiment
   result was reported in the v6ops BoF on IETF 82 Taipei.  In the 1st
   experiment, we constructed an IPv6 only network with stateless NAT64
   and DNS64 as a part of the WIDE backbone through IPv6 L2TP over a
   commercial IPv6 network service.  The commercial IPv6 network service
   was provided by NTT-East as an Access Carrier, Internet MultiFeed
   (MFeed) as a Virtual Network Enabler (VNE) and IIJ as an IPv6
   Internet Service Provider (IPv6 ISP).  In addition to an IPv6
   connectivity with NAT64/DNS64, we also tested a SA46T
   [I-D.draft-matsuhira-sa46t-spec] based IPv4 global network service
   and a murakami-4RD [I-D.draft-murakami-softwire-4rd] based IPv4
   private network service (murakami-4RD is now merged into MAP
   [I-D.draft-ietf-softwire-map-02]).  With referring IETF's IPv6 only
   network experiences [RFC6586], we reported several new issues on an
   IPv6 only network with IPv4 / IPv6 transition technologies,
   especially on inappropriate DNS replies mentioned in [RFC4074], on
   MTU mismatch, on VPN protocols and applications through IPv4 / IPv6
   translators.

1.1.2.  Summary of the 2nd experiment

   According to the experiences on the 1st experiment, the 2nd
   experiment was conducted from March 5th to March 8th, 2012 in
   Matsushiro Royal Hotel, the same hotel of the 1st experiment. 171
   participants joined this 2nd experiment, most of them were engineers



Hazeyama, et al.          Expires April 6, 2013                 [Page 4]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   or academic people.  The 2nd experiment result was reported in the
   v6ops BoF on IETF 83 Paris.

   The settings of the core network in the 2nd experiment was same as
   the 1st experiment.  In the 1st experiment, a commercial IPv6 network
   service was employed as a backbone network, in other word, we did
   evaluate the availability of commercial IPv6 network services from
   the view of home users.  Therefore, the evaluation target of the 2nd
   experiment was planned as living in commercial IPv6 networks with
   IPv4 / IPv6 translation technologies or IPv4 / IPv6 translation
   services.

   The user access networks of the 2nd experiment were achieved by two
   types of commercial IPv6 network services through the NTT NGNv6
   access network, with four kinds of IPv4 / IPv6 translation
   technologies.  One of the two commercial IPv6 network services was
   /48 prefix IPv6 network service through IPoE[RFC0894] on NTT NGNv6
   (we name it "native IPoE" in this draft), the other was /56 prefix
   IPv6 network service through PPPoE[RFC2516] on NTT NGNv6 (we label it
   "native PPPoE" in this draft) [YasudaAPRICOT2011].  Both IPv6
   networks were served from NTT-East, MFeed and IIJ as same as the 1st
   experiment.

   Usually, IPv6 networks on both native IPoE and native PPPoE were
   provided with only DNS v6 proxy.  We constructed DNS64/NAT64 service
   on the WIDE backbone and on the camp core network, and served it
   through stateless DHCP6 [RFC3736] both on native IPoE and on native
   PPPoE.

   Along with the DNS64/NAT64 translation service, for aiming to
   evaluate more practical approaches on the current commercial
   environments, we tested three IPv4 services over IPv6 networks,
   murakami-4RD [I-D.draft-murakami-softwire-4rd], SA46T
   [I-D.draft-matsuhira-sa46t-spec] and 464XLAT
   [I-D.draft-ietf-v6ops-464xlat].  We mainly served seven IP networks
   to participants by combination of those networks and translation
   services, that is, native IPoE with DNS64/NAT64, native PPPoE with
   DNS64/NAT64, murakami-4RD on both IPoE and PPPoE, 464XLAT on both
   IPoE and PPPoE, SA46T on PPPoE.

   Three evaluations were mainly conducted by the evaluation team, i)
   user survey about the availability of each network through face to
   face interview, ii) analysis of DNS behaviors to grasp inappropriate
   behaviors mentioned in [RFC4074], iii) availability test of VPN
   applications to analyze MTU problems For to grasp whether an
   unavailability of VPN applications was intentional one due to the
   specification of a translation technology or not.  Also, Konami
   Digital Entertainment (KDE) joined in this experiment, and evaluated



Hazeyama, et al.          Expires April 6, 2013                 [Page 5]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   NAT/Firewall traversal testing on each IPv6 network or each
   translator service from the view of commercial (P2P) Network Game
   services.  KDE gave us the importance / requirements of hair-pinning
   functions and of MTU / packet fragmentation handling on NAT/NAPT for
   P2P based Multiplayer Online Games.

1.2.  Abstract of the 3rd experiment

   The 3rd experiment was conducted from September 3rd to September 6th,
   2012 in Matsushiro Royal Hotel, the same hotel of the past two
   experiments. 136 participants joined this 3rd experiment, most of
   them were engineers or academic people.

   The aims of 3rd experiments were 1) continuous user survey on IPv6
   capability of devices, OSes and applications, 2) exploration of a
   practical solution to mitigate timeout / fallback problems of IPv4/
   IPv6 dual stack clients on an IPv6 only network.

   The first aim was conducted to grasp the IPv6 capability of users'
   devices, OSes, and applications and to collect users' experiences
   through face to face interview.  From the 2nd experiments, several
   new OSes or new devices have been released.  Through this continuous
   survey, we saw the current development / deployment strategy of IPv6
   on commercial vendors or Telecom / Internet Service providers.  This
   user survey was mainly carried on September 3rd and September 4th.

   The second aim was derived from our experiences of an IPv6 only
   network with DHCP6/DNS64/NAT64 on past two experiments.  In past two
   experiments, various OSes met several timeout / fallback problems, in
   the initial connection setting through Wi-Fi settings, in the name
   server selection, in the establishment of a TCP connection.  Most
   OSes and applications, that met tedious timeout / fallback problems,
   preferred IPv4 to IPv6, or required IPv4 settings to enable IPv6
   settings.  These timeout / fallback problems were seemed to be
   derived from an assumption that there are no IPv6 only network on the
   current situation.

   Toward the sunset of IPv4, we have to explore and achieve a practical
   solution to move from IPv4/IPv6 dual stack networks to IPv6 only
   networks without giving stress or difficulties to end users.  In
   IPv4/IPv6 transition situation, end users will usually use IPv4/IPv6
   dual stack mode, and they will leave all IPv4 / IPv6 network settings
   by OSes' auto configuration behaviors on their devices except for
   selecting Wi-Fi connections.

   We focused on testing an IPv6 only network that was basically
   composed of DHCP6, DNS64 and NAT64.  In this IPv6 only network, we
   sought a current practice of timeout / fallback mitigation among



Hazeyama, et al.          Expires April 6, 2013                 [Page 6]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   IPv4/IPv6 dual stack networks and IPv6 only networks.  According to
   results of the user survey, we added several functions to a basic
   DHCP6/DNS64/NAT64 network in step by step fashion, and we analyzed or
   revised mitigation methods for timeout / fallback problems.

   This draft is composed of following sections.  We explain the
   overview of the network settings in the 3rd experiment at first.
   Next, we report the result of the user survey.  Then, we describe the
   experiment on timeout / fallback mitigation methods.  Finally, we
   summarize our practical timeout / fallback mitigation method.  We
   also mention about limitations our mitigation method and our
   recommendations on development / deployment of IPv6 capability on end
   clients.

1.3.  Requirements Language

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


2.  Technology and Terminology

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

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

   "NAT64" refers to a Network Address Translator - Protocol Translator
   defined in [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6384].

   "DNS64" refers DNS extensions to use NAT64 translation from IPv6
   clients to IPv4 servers with name resolution mechanisms that is
   defined in [RFC6147].

   "DHCP4" refers Dynamic Host Configuration Protocol for IPv4 that is
   defined in [RFC2131].

   "DHCP6" refers Dynamic Host Configuration Protocol for IPv6.  So
   called "Stateful DHCP6" is defined in [RFC3315] and "Stateless DHCP6"
   is defined in [RFC3736].  "DHCP-PD" or "DHCPv6 Prefix Delegation"
   refers IPv6 Prefix Options for DHCP6 that is initially defined in
   [RFC3633] and updated in [RFC6603].




Hazeyama, et al.          Expires April 6, 2013                 [Page 7]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   "ND" refers Neighbor Discovery for IP version 6 (IPv6) that is
   defined in [RFC4861] and updated in [RFC5942].


3.  Basic configuration of Network and Experiments

   The WIDE Camp Autumn 2012 was held at Matsushiro Royal Hotel in
   Nagano Prefecture of Japan, the same place of the 1st and 2nd
   experiment, from September 3rd to September 6th, 2012.  Figure 1
   shows the overview of the whole network topology on the WIDE Camp
   Autumn 2012.

   Besides our IPv6 only experiments, the camp NOC team set up a core
   network (camp-net-core) for preparing a backup plan of our IPv6 only
   network experiments and for conducting other experiments such as OLSR
   emulation, SA46T-AT [I-D.draft-matsuhira-sa46t-at-00] and NAT44
   double translation, and measurement of a satellite link.  All server
   instances and routing instances of the core network were built on
   StarBED that is a cloud / network emulation testbed in Japan.  We
   constructed two layer 2 tunnels between StarBED and Matsushiro Royal
   hotel through IPv4 PPPoE.  The layer 2 tunnels over IPv4 PPPoE were
   constructed by NEC IX2015.  The OLSR network and the satellite link
   were served as IPv4 / IPv6 dual stack networks.  The wireless
   Accesses to these networks were provided by CISCO Systems Mesh Wi-Fi
   Access Point and WLC (Wireless LAN Controller).

   As well as our 2nd experiment, a commercial IPv6 service was employed
   to achieve our IPv6 only network experiments.  The Access Carrier
   (AC), the Virtual Network Enabler (VNE) and the IPv6 Internet Service
   Provider (v6ISP) of this 3rd experiment were same combination of past
   experiments, that is, NTT-East as AC, MFeed as the VNE and IIJ Mio as
   v6ISP.  We contracted two external FTTH lines by NTT NGNv6 IPoE
   method.  We changed the IPv6 address allocation method on NTT NGNv6
   IPoE during this camp.

   From September 2th (the preparation day) to September 4th, we used
   the RA method for the external connectivity.  Figure 2 represents
   details of the IPv6 only network by RA method.  From September 5th to
   September 6th, we changed the external connectivity to the DHCP-PD
   method.

   In the RA method, we tested the DHCP6 client behaviors when two
   stateless DHCP6 servers exist, one is placed by the VNE or ISP to
   indicate AAAA name servers, the other is located in the local subnet
   to lead clients to a DNS64 name server.  On the other hand, we
   explored mitigation methods for timeout / fallback problems after we
   changed the external connectivity to the DHCP-PD method.  We explain
   the experiment on the RA method in Section 4.1 and the experiments on



Hazeyama, et al.          Expires April 6, 2013                 [Page 8]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   the DHCP-PD method in Section 4.2, respectively.

   We employed following implementations for key components;

   o  DNS64 and recursive cache server: NLNet Labs Unbound 1.4.7 with
      DNS64 patch

   o  NAT64 : OpenBSD 5.1 PF (Packet Filter)

   o  DHCP-PD client : WIDE DHCP client (dhcp6c)

   o  Stateless DHCP6 server : Alaxala 3630







































Hazeyama, et al.          Expires April 6, 2013                 [Page 9]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


       +----------------------------------------------------+
       |               The Internet  (IPv4 / IPv6)          |
       +----------------------------------------------------+
              |     |                      |
              |     |                      |
     +-----------+  |               +--------------+
     | IIJ (ISP) |  |               |  WIDE (ISP)  |---------+
     +-----------+  |               +--------------+         |
              |     |                  |         |           |
              |     |                  |      (L2 Tunnel)    |
              |     |             (IPv4/IPv6)    |           |
              |     |                  |     +---------+     |
              |     |                  |     | IX 2015 |     |
           +-----------+               |     +---------+     |
           |MFeed (VNE)|               |         |           |
           +-----------+          +---------------+  +-------------+
                  |               | camp-net-core |  | SAT station |
                  |               +---------------+  +-------------+
                  |                                          |
      +--------------------------+                           |
      |  NTT NGNv6 (Access Line) |                  (satellite link)
      +--------------------------+                           |
           |      |                                  +-------------+
         (IPoE method)                               | SAT station |
           |      |                                  +-------------+
           |      +--------------+                           |
           |      |              |                           |
        (native IPv6)  (L2 tunnel over IPv4 PPPoE)       (L2 Tunnel)
           |      |              |                           |
           |      |        +---------+                  +---------+
           |      |        | IX 2015 |                  | IX 2015 |
           |      |        +---------+                  +---------+
           |      |              |                           |
           |      |           (vlan)                      (vlan)
           |      |              |                           |
    +------------------------------------------------------------+
    |      Wi-fi Access (CISCO  Layer 2 mesh, 11b/g/n Wi-fi)     |
    +------------------------------------------------------------+



                 Over view of the 2nd experiment topology

                                 Figure 1







Hazeyama, et al.          Expires April 6, 2013                [Page 10]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


4.  Experiments

4.1.  An Experiment in RA method

4.1.1.  Details of Network Configuration

   The experiment conducted in RA method was overwriting client DNS
   information by a local stateless DHCP6 server.  Figure 2 shows the
   test network topology.  The RA method provided /64 prefix addresses
   and routing information through RA.  The RA was set managed flag as
   zero (M flag == 0) and the other flag to one (O flag == 1) to let
   clients query to stateless DHCP6 servers.  In this case, a stateless
   DHCP6 server was placed on the VNE network of MFeed and IIJ that
   advertised two AAAA name servers.  Those two AAAA name servers
   returned only AAAA records to any queries.

   We wanted to inform only the DNS64 IPv6 address to clients on this RA
   method while using address assignment and default route settings by
   the RA method.  Of course, we could not control the DHCP6 server on
   the VNE network.  Therefore, we tried to use the preference option of
   DHCP6.

   The preference option of DHCP6 (section 22.8 of [RFC3315]) defines
   that "the Preference option is sent by a server to a client to affect
   the selection of a server by the client".  Section 17.1.3 of
   [RFC3315] defines the criteria on the behavior of DHCP6 server
   selection by a client when the client has received two or more valid
   advertise messages;

   o  Those Advertise messages with the highest server preference value
      are preferred over all other Advertise messages.

   o  Within a group of Advertise messages with the same server
      preference value, a client MAY select those servers whose
      Advertise messages advertise information of interest to the
      client.  For example, the client may choose a server that returned
      an advertisement with configuration options of interest to the
      client.

   o  The client MAY choose a less-preferred server if that server has a
      better set of advertised parameters, such as the available
      addresses advertised in IAs.

   We assumed we could overwrite the name server information by sending
   advertise messages with highest preference value from a local
   stateless DHCP6 server.  Thus, we placed a local stateless DHCP6
   server shown in Figure 2.




Hazeyama, et al.          Expires April 6, 2013                [Page 11]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   This overwriting was partially succeeded as well as we assumed,
   however, several inconveniences were reported through face to face
   interview and inspection by the special observation team.


                                              +-------+ +------+
                                              | DNS64 | | NAT64|
                                              +-------+ +------+
                                                  |        |
                                                (-- StarBED --)
                                                  |        |
       +--------------- IPv6 Internet ----------------------+
             |
       +-------------+
       | IPv6 router |
       |   on ISP    |
       +-------------+
             |
       +---------+  +---------+  +----------+             +---------+
       | IPv6 GW |  | DHCP6   |  |AAAA name |             | DHCP6   |
       |         |  | to AAAA |  | servers  |             | to DNS64|
       +---------+  +---------+  +----------+             +---------+
             |         |               |                     |
           (----------  VNE  --------------)             (-- Hotel --)
             |         |               |                     |
       +----------------  /64 prefix segment -----------------------+
                                                         |
                                                     +---------------+
                                                     | users devices |
                                                     +---------------+


                      The Test Topology on RA method

                                 Figure 2

4.1.2.  User Survey

   59 participants (42.8 %) replied our face to face interview.  We show
   the client profile in Section 4.1.2.1 and reported troubles in
   Section 4.1.2.2 and Section 4.1.2.3.

4.1.2.1.  Client Profile

   94 unique devices were profiled.  The distribution of the pair of
   device and OS were shown in Table 1.





Hazeyama, et al.          Expires April 6, 2013                [Page 12]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


     +-------------------+----------------------+-------------------+
     |    Device Type    |        OS Type       |  # of devices (%) |
     +-------------------+----------------------+-------------------+
     |   PC/AT Note PC   |       Windows 7      |    16 (17.0 %)    |
     | ----------------- |   -----------------  | ----------------- |
     |   PC/AT Note PC   |        NetBSD        |     2 (2.1 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   PC/AT Note PC   |         Linux        |     4 (4.3 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   Apple Note PC   |     Mountain Lion    |    15 (16.0 %)    |
     | ----------------- |   -----------------  | ----------------- |
     |   Apple Note PC   |         Lion         |     18 (19.1%)    |
     | ----------------- |   -----------------  | ----------------- |
     |   Apple Note PC   |     Snow Leopard     |     9 (9.6 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   Apple Note PC   | Windows 7 (Bootcamp) |     3 (3.2 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   iPhone / iPod   |         iOS 5        |     9 (9.6 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   Android Phone   |     Android OS 4     |     3 (3.2 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   Android Phone   |     Android OS 2     |     4 (4.3 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   Android Phone   |     Android OS 1     |     1 (1.0 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |        iPad       |         iOS 6        |     1 (1.0 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |        iPad       |         iOS 5        |     6 (6.4 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |   Android Tablet  |     Android OS 4     |     2 (2.1 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |       Kindle      |      Kindle 3.3      |     1 (1.0 %)     |
     | ----------------- |   -----------------  | ----------------- |
     |       Total       |                      |         94        |
     +-------------------+----------------------+-------------------+

           Table 1: The distributions of devices of participants

4.1.2.2.  Behaviors of DHCP6 Clients

   Many users reported inconveniences of DHCP6 client behaviors in the
   RA method.  We focused on the analysis of DHCP6 client behavior of
   Windows 7 and of Mac OS X Lion / Mountain Lion.  Both Windows 7 and
   Mac OS X usually stored DNS64 IPv6 address to their name server
   information, however, both of them sometime stored two AAAA name
   servers on the VNE network.  Differences of their DHCP6 client
   behaviors were as follows;




Hazeyama, et al.          Expires April 6, 2013                [Page 13]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   o  In most cases, Windows 7 preferred to the advertise message from
      the local DHCP6 server that indicated the DNS64 server, however,
      it often preferred the advertise message from the DHCP6 server on
      the VNE network at the RA refresh timing.

      *  When the DHCP6 client preferred to the DHCP6 server on the VNE
         network, an user had to reset the Wi-Fi device of his/her PC
         and to reconnect to the Wi-Fi network. "ipconfig /renew" or
         simply reconnecting by Wi-Fi selection icon often failed to
         prefer the advertise message from the local DHCP6 server.

   o  On the other hand, Mac OS X Lion and Mountain Lion often failed to
      prefer the advertise message from the local DHCP6 server at the
      initial set up on Wi-Fi setting, however, "Renew DHCP lease" on
      the detail of network settings always preferred to the advertise
      message from the local DHCP6 server, that is, Mac OS X always
      changed the name server setting to only DNS64 IPv6 address by
      "Renew DHCP lease".  At RA refresh timing, Mac OS X sometime
      preferred to the DHCP6 server on the VNE network, then, the user
      had to refresh DHCP configurations again.

4.1.2.3.  Timeout / Fallback Problems

   Many users reported inconveniences due to timeout / fallback
   problems.  Root causes were roughly categorized into 1) troubles of
   DNS64, 2) incapability of IPv6 and of DNS64 on various servers and
   applications mentioned in [RFC4074] and [RFC6586], 3) incapability of
   DHCP6 client and / or IPv4 dependency on OSes.  In Section 4.2, we
   explain the detail of timeout / fallback problems without effects by
   the selection of stateless DHCP6 servers.

4.2.  Experiments in DHCP-PD method

   On the contrary of the RA method mentioned in Section 4.1, the
   DHCP-PD method provided /56 prefix delegation by DHCP6 prefix
   delegation mechanism.  We settled a DHCP-PD client PC router and set
   up static routes to two delegated /64 networks, one was labeled as
   "v6only-basic", the other was named as "v6only-fallback".  The
   v6only-basic network was a basic IPv6 only network that was composed
   of stateless DHCP6, DNS64 and NAT64.  On the other hand, we tested
   several timeout / fallback mitigation methods in "v6only-fallback".
   Figure 3 shows the basic network topology of experiments on DHCP-PD
   method.

4.2.1.  Basic Network Configuration

   Figure 3 shows the basic network topology of experiments on DHCP-PD
   method.



Hazeyama, et al.          Expires April 6, 2013                [Page 14]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


                                              +-------+ +------+
                                              | DNS64 | | NAT64|
                                              +-------+ +------+
                                                  |        |
                                                (-- StarBED --)
                                                  |        |
       +--------------- IPv6 Internet ----------------------+
                              |
                      +-------------+      +----------------+
                      | IPv6 router |      | DHCP PD server |
                      |   on ISP    |      |    on VNE      |
                      +-------------+      +----------------+
                              |                    |
    +-- (VNE network) ----------------+----------------------+
                                      |
                                      |(v6)
                                      |
                               (---- Hotel ----)
                                      |
                                +---------------+
                                | DHCP-PD Client|
                                |  PC router    |
                                +---------------+
                                      |
      +-----------------+             |
      | Stateless DHCP6 |             |
      +-----------------+             |
                 |                    |
                 |                    |
       +------------- each /64 prefix segment ---------------+
                                              |
                                      +---------------+
                                      | users devices |
                                      +---------------+


          Basic Network Topology on DHCP-PD method (v6only-basic)

                                 Figure 3

4.2.2.  Experiment 0

   In the experiment 0, we observed OSes behaviors again.  Actually, the
   inconvenience on the selection of two stateless DHCP6 servers were
   resolved by DHCP-PD and placing one stateless DHCP6 server onto each
   /64 prefix subnet.  However, we clearly recognized several timeout /
   fallback problems.  In following sections, we explain timeout /
   fallback problems due to DHCP6 client incapability and IPv4



Hazeyama, et al.          Expires April 6, 2013                [Page 15]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   dependency of OSes.

4.2.2.1.  Waiting timeout of DHCP4 in Windows 7

   In Windows 7, timeout of DHCP4 queries spent a few minutes in the
   initial Wi-Fi connection setup.  After fallback on the initial Wi-Fi
   connection, there were no problem on using IPv6 capable applications.
   DNS64 fallback failures due to the inappropriate authoritative
   servers still occurred, however, several authoritative servers, that
   returned inappropriate AAAA reply in past experiments, had been fixed
   to have appropriate fallback.

4.2.2.2.  Long TCP fallback in Mac OS X Lion and Mountain Lion

   Mac OS X implementations, such as Lion and Mountain Lion, had more
   serious timeout / fallback problems than Windows 7.  After the
   timeout of DHCP4 queries with a few minutes as well as Windows 7, the
   interface that is allocated IPv4 link local address was inserted as
   IPv4 default route.  This Mac OS X behavior may be along with IPv4
   on-link assumption in Section 3.3 of [RFC3927].  Section 3.3 of
   RFC3927 mentions "Interaction with Hosts with Routable Addresses",
   which assumes all IPv4 address are on-link at Link-Local
   configuration.

   Also, getaddrinfo implementation on Mac OS X did HappyEyeball like
   behavior.  The getaddrinfo of Mac OS X returned an IP address list
   where IPv4 addresses were inserted the top of the list initially.
   Combining the on-link-assumption and the HappyEyeball like
   getaddrinfo caused long long TCP fallback from IPv4 to IPv6 in the
   initial TCP connection setup.  Once the long long TCP fallback
   occurred, getaddrinfo of Mac OS X marked some flag that IPv4 is not
   available at the moment, then the getaddrinfo gave higher priority to
   IPv6 addresses than IPv4 addresses until ARP and / or ND tables were
   refreshed.  When ARP and / or ND tables were refreshed, Mac OS X
   users face long long TCP fallback from IPv4 to IPv6 again.

4.2.2.3.  Incompletion of network settings in iOS 5

   In iOS 5, "Network Setting" were not completed, "Network Settings"
   will be completed only if IPv4 address, IPv4 router, and IPv4 DNS can
   be retrieved via DHCPv4 or manually configured all of these 3.

4.2.2.4.  Incapability of IPv6 DNS settings by DHCP6

   Windows XP, older Mac OS X (Snow Leopard and older) and Android OS
   required an IPv4 address for an DNS server even when they can use
   IPv6.  In an IPv6 only network, DNS information should be gotten via
   DHCP6, these OSes did not support DHCP6 client.  Also, Android cannot



Hazeyama, et al.          Expires April 6, 2013                [Page 16]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   be configured to use DNS over IPv6 even in manual configuration.

4.2.3.  Experiment 1

4.2.3.1.  Diff of network settings

   In the Experiment 1, we added a DHCP4 server that provided only IPv4
   private address to DHCP4 client without the default gateway IPv4
   address nor IPv4 address of DNS.  We employed ISC-DHCP for this DHCP4
   server.









































Hazeyama, et al.          Expires April 6, 2013                [Page 17]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


                                              +-------+ +------+
                                              | DNS64 | | NAT64|
                                              +-------+ +------+
                                                  |        |
                                                (-- StarBED --)
                                                  |        |
       +--------------- IPv6 Internet ----------------------+
                              |
                      +-------------+      +----------------+
                      | IPv6 router |      | DHCP PD server |
                      |   on ISP    |      |    on VNE      |
                      +-------------+      +----------------+
                              |                    |
    +-- (VNE network) ----------------+----------------------+
                                      |
                                      |(v6)
                                      |
                               (---- Hotel ----)
                                      |
                                +---------------+
                                | DHCP-PD Client|
                                |  PC router /  |
                                |    DHCP4      |
                                +---------------+
                                      |
      +-----------------+             |
      | Stateless DHCP6 |             |
      +-----------------+             |
                 |                    |
                 |                    |
       +------------- /64 prefix segment ---------------+
                                              |
                                      +---------------+
                                      | users devices |
                                      +---------------+


              Test Topology on Experiment 1 (v6only-fallback)

                                 Figure 4

4.2.3.2.  Result

   As the result of Experiment 1, only timeout of DHCP4 was solved, that
   is, only Windows 7 was working well without any fallback problems
   except for DNS64 name resolving.  TCP fallback problem on MacOS X
   still occurred. iOS applications were sometimes working, but
   periodically failed due to retrying Wi-Fi connection setup.



Hazeyama, et al.          Expires April 6, 2013                [Page 18]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


4.2.4.  Experiment 2

4.2.4.1.  Diff of network settings

   In the Experiment 2, we put BIND9 forwarder on-link and configured
   DHCP4/6 to use this DNS.  We configured BIND9 forwarder with: * deny-
   answer-addresses { 0.0.0.0/0; }; * which directed that no IPv4
   address answer should be trusted.  It returned SERVFAIL to resolvers.











































Hazeyama, et al.          Expires April 6, 2013                [Page 19]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


                                              +-------+ +------+
                                              | DNS64 | | NAT64|
                                              +-------+ +------+
                                                  |        |
                                                (-- StarBED --)
                                                  |        |
       +--------------- IPv6 Internet ----------------------+
                              |
                      +-------------+      +----------------+
                      | IPv6 router |      | DHCP PD server |
                      |   on ISP    |      |    on VNE      |
                      +-------------+      +----------------+
                              |                    |
    +-- (VNE network) ----------------+----------------------+
                                      |
                                      |(v6)
                                      |
                               (---- Hotel ----)
                                      |
                                +------------------+
                                | DHCP-PD Client   |
                                |  PC router /     |
                                |    DHCP4 /       |
                                | Bind 9 forwarder |
                                | which treats "A" |
                                | as SERVAFAIL     |
                                +------------------+
                                      |
      +-----------------+             |
      | Stateless DHCP6 |             |
      +-----------------+             |
                 |                    |
                 |                    |
       +------------- /64 prefix segment ---------------+
                                              |
                                      +---------------+
                                      | users devices |
                                      +---------------+


              Test Topology on Experiment 2 (v6only-fallback)

                                 Figure 5








Hazeyama, et al.          Expires April 6, 2013                [Page 20]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


4.2.4.2.  Result

   As result of Experiment 2, Android was working well. iOS was working,
   but periodically failed due to retrying to Wi-Fi connection setup.
   MacOS X variants were working, but timeout by TCP fallback still
   occurred.  Windows XP was not working because all DNS queries failed
   due to SERVFAIL.

4.2.5.  Experiment 3

4.2.5.1.  Diff of network settings

   In the Experiment 3, we hacked AAAA filtering code on BIND9 to filter
   "A records" instead of "AAAA records" both on IPv4/IPv6 transport.
   We put BIND9 above to the local link, which was configured to forward
   all queries to DNS64.  We also configured DHCP4/DHCP6 to use the DNS
   proxy.


































Hazeyama, et al.          Expires April 6, 2013                [Page 21]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


                                              +-------+ +------+
                                              | DNS64 | | NAT64|
                                              +-------+ +------+
                                                  |        |
                                                (-- StarBED --)
                                                  |        |
       +--------------- IPv6 Internet ----------------------+
                              |
                      +-------------+      +----------------+
                      | IPv6 router |      | DHCP PD server |
                      |   on ISP    |      |    on VNE      |
                      +-------------+      +----------------+
                              |                    |
    +-- (VNE network) ----------------+----------------------+
                                      |
                                      |(v6)
                                      |
                               (---- Hotel ----)
                                      |
                                +-------------------+
                                | DHCP-PD Client    |
                                |  PC router /      |
                                |    DHCP4 /        |
                                | Bind 9 DNS Proxy  |
                                |  with "A" filter  |
                                +-------------------+
                                      |
      +-----------------+             |
      | Stateless DHCP6 |             |
      +-----------------+             |
                 |                    |
                 |                    |
       +------------- /64 prefix segment ---------------+
                                              |
                                      +---------------+
                                      | users devices |
                                      +---------------+


              Test Topology on Experiment 3 (v6only-fallback)

                                 Figure 6

4.2.5.2.  Result

   As the result of Experiment 3, Windows XP, MacOS X variants, iOS,
   Android were working well.  Some of applications still failed on IPv6
   only due to the IPv6 incapability or DNS64 fallback problem, but many



Hazeyama, et al.          Expires April 6, 2013                [Page 22]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   cases were fine: IE/Safari/Chrome/Firefox, Twitter, Facebook,
   Instagram, and so on.

   Remaining issues were connection failures during a few minutes after
   Wi-Fi was connected.  We guess the possible reason of this failures
   as follows: RS (Router Solicitation) was sent from kernel before
   Wi-Fi link was established.  No IPv6 address was obtained until
   periodical RA (Router Advertisement) was received.  The possible
   workaround to this connection failure is shortening RA interval to
   5-10 seconds (though it disturb Wi-Fi ...) or detecting association
   through AP log and kicking RS or RA.


5.  Conclusion

   Timeout / fallback problems on IPv4/IPv6 dual stack clients in an
   IPv6 only network are caused by

   1.  timeout and fallback sequence on DHCP4 queries,

   2.  timeout and fallback sequence on the connectivity check to the
       IPv4 internet after the DHCP4 auto configuration,

   3.  connection retry sequence when the connectivity to the IPv4
       internet was not given.

   4.  timeout and fallback sequence of a TCP connection on Mac OS X
       variants due to their HappyEyeball like behavior of getaddrinfo,

   5.  preference / dependency of IPv4 on name resolution,

   6.  connection failures during 1-2 minutes after Wi-Fi was connected.

   To mitigate these timeout / fallback problems, our current practice
   is composed of following components;

   o  Configure a DNS64 and a NAT64 in somewhere.

   o  Configure a Dual-stack DNS proxy as follows

      *  The DNS proxy forwards all queries to the DNS64 except "A"
         query type (IPv4 address).  Since there is no IPv4 connectivity
         on the client, all queries to "A" should be filtered and the
         DNS proxy returns NO DATA, just like "AAAA" filtering.

      *  This "A" filter should be enabled both on IPv4 and IPv6
         transport.




Hazeyama, et al.          Expires April 6, 2013                [Page 23]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


      *  This Dual-stack "A" filter DNS proxy should be "on-link" and
         reachable from IPv4/IPv6 dual stack mode clients.

   o  Configure a DHCP4 server to reply a private IPv4 address, an IPv4
      gateway router, and IPv4 address of an "A" filter DNS proxy to
      DHCP4 client.

   o  Configure a DHCP6 server to indicate the IPv6 address of "A"
      filter DNS Proxy to DHCP6 client.

      *  The IPv6 address of "A" filter DNS Proxy may be provided to
         IPv4/IPv6 dual stack mode clients by RDNSS [RFC6106].  However,
         from our experience on hot stage of Camp 1209 Autumn, Mac OS X
         Lion and Mountain Lion could handle RDNSS, but Windows 7 did
         not handle RDNSS.

      *  Only one DHCP6 server should be placed in each /64 prefix
         segment or indicated by DHCP6 relay.  According to our
         experience, we do not recommend overwriting DNS information by
         a local stateless DHCP6 server with highest preference value
         due to the differences of handling multiple DHCP6 replies among
         DHCP6 client implementations.

   o  Configure the IPv4 gateway router not to forward any IPv4 packets.


6.  Security Considerations

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


7.  IANA Considerations

   This document has no IANA implications.


8.  References

8.1.  Normative References

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

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address



Hazeyama, et al.          Expires April 6, 2013                [Page 24]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

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

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

8.2.  Informative References

   [I-D.draft-ietf-softwire-map-02]
              Troan, O., Bao, C., Matsushima, S., and T. Murakami,
              "Mapping of Address and Port with Encapsulation (MAP)",
              September 5, 2012, <draft-ietf-softwire-map-02 (work in
              progress)>.

   [I-D.draft-ietf-v6ops-464xlat]
              Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              September 2012, <draft-ietf-v6ops-464xlat-08 (work in
              progress)>.

   [I-D.draft-matsuhira-sa46t-at-00]
              Matsuhira, N., Horiba, K., Ueno, Y., and O. Nakamura,
              "SA46T Address Translator", July 2011,
              <draft-matsuhira-sa46t-at-00 (work in progress)>.

   [I-D.draft-matsuhira-sa46t-spec]
              Matsuhira, N., "Stateless Automatic IPv4 over IPv6
              Tunneling: Specification", July 2012,
              <draft-matsuhira-sa46t-spec-05 (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)>.

   [RFC0894]  Hornig, C., "Standard for the transmission of IP datagrams
              over Ethernet networks", STD 41, RFC 894, April 1984.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.



Hazeyama, et al.          Expires April 6, 2013                [Page 25]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5942]  Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
              Model: The Relationship between Links and Subnet
              Prefixes", RFC 5942, July 2010.

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

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

   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation", RFC 6144, April 2011.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6147]  Bagnulo, M., Sullivan, A., Matthews, P., and I. van
              Beijnum, "DNS64: DNS Extensions for Network Address
              Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
              April 2011.

   [RFC6384]  van Beijnum, I., "An FTP Application Layer Gateway (ALG)
              for IPv6-to-IPv4 Translation", RFC 6384, October 2011.



Hazeyama, et al.          Expires April 6, 2013                [Page 26]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [RFC6603]  Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
              "Prefix Exclude Option for DHCPv6-based Prefix
              Delegation", RFC 6603, May 2012.

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


Appendix A.  Acknowledgments

   Here, we thank to all the participants of WIDE camp on the
   experiments.  We also say thank you to whom serving implementations
   and services in the Matsushiro Royal Hotel.

   R. Nakamura of Univ. of Tokyo, Y. Ueno of Keio Univ. and R. Shouhara
   of Univ. of Tokyo for helping us on the base settings of the IPv6
   only experiments and merging into the camp-net.

   O. Onoe of Sony Corporation for his deep inspection and testing of
   end node devices.

   T. Jimei of Internet Systems Consortium for his quick hack on A
   filter of Bind 9.

   Y. Atarashi of Alaxala Networks and R. Atarashi of IIJ Innovation
   Institute for designing the items of face to face interview and
   analyzing user survey data.


Authors' Addresses

   Hiroaki Hazeyama
   NAIST
   Takayama 8916-5
   Nara,
   Japan

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






Hazeyama, et al.          Expires April 6, 2013                [Page 27]

Internet-Draft      IPv6 Experiments in the WIDE Camp       October 2012


   Ruri Hiromi
   Intec Inc.
   1-3-3 Shin-Suna, Koutou
   Tokyo,
   Japan

   Email: hiromi@inetcore.com


   Tomohiro Ishihara
   Univ. of Tokyo
   3-8-1 Komaba, Meguro
   Tokyo,
   Japan

   Email: sho@c.u-tokyo.ac.jp


   Osamu Nakamura
   WIDE Project
   5322 Endo
   Kanagawa,
   Japan

   Email: osamu@wide.ad.jp


























Hazeyama, et al.          Expires April 6, 2013                [Page 28]