[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                        H. Hazeyama
Internet-Draft                                                     NAIST
Intended status: Informational                                 R. Hiromi
Expires: September 14, 2012                                   Intec Inc.
                                                             T. Ishihara
                                                          Univ. of Tokyo
                                                             O. Nakamura
                                                            WIDE Project
                                                          March 13, 2012


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

Abstract

   This document reports and discusses issues on IPv6 only networks and
   IPv4/IPv6 transition technologies through our experiences on the 2nd
   experiment on the WIDE camp.  The second experiment was held from
   March 4th to March 8th, 2012.  We tried to live in commercial IPv6
   networks with four kinds of IPv4/IPv6 transition technologies, DNS64/
   NAT64, 4RD, 464XLAT and SA46T. In this -01.txt aims to report results
   of the 2nd experiment and to share issues / problems on the IPv4 /
   IPv6 transition that we met.

Status of this Memo

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

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

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

   This Internet-Draft will expire on September 14, 2012.

Copyright Notice

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




Hazeyama, et al.       Expires September 14, 2012               [Page 1]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


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










































Hazeyama, et al.       Expires September 14, 2012               [Page 2]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  History of ``Live with IPv6 experiment'' on the WIDE
           camp . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.1.1.  Summary of the 1st experiment  . . . . . . . . . . . .  5
       1.1.2.  Abstract of the 2nd experiment . . . . . . . . . . . .  5
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
   2.  Technology and Terminology . . . . . . . . . . . . . . . . . .  7
   3.  Network and Experiment Setup . . . . . . . . . . . . . . . . .  7
     3.1.  IPv6 networks  . . . . . . . . . . . . . . . . . . . . . . 10
     3.2.  IPv4 networks  . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  DNS Settings . . . . . . . . . . . . . . . . . . . . . . . 12
     3.4.  NAT64 Settings . . . . . . . . . . . . . . . . . . . . . . 13
     3.5.  Wireless networks  . . . . . . . . . . . . . . . . . . . . 13
     3.6.  Settings for MTU and NAT / Firewall Traversal Tests
           for commercial (P2P) Network Games . . . . . . . . . . . . 15
   4.  Experiences from the Experiments . . . . . . . . . . . . . . . 15
     4.1.  User Survey by face-to-face interview  . . . . . . . . . . 15
       4.1.1.  Client Profile . . . . . . . . . . . . . . . . . . . . 15
       4.1.2.  Reported Troubles  . . . . . . . . . . . . . . . . . . 17
         4.1.2.1.  Failure of IPv6 neighbor discovery due to the
                   on-link assumption of IPv4 network . . . . . . . . 17
         4.1.2.2.  Locked out IPv6 by vendor  . . . . . . . . . . . . 18
         4.1.2.3.  Inappropriate selection of DNS resolvers . . . . . 18
         4.1.2.4.  Previous configuration lived after moving to
                   another WiFi network . . . . . . . . . . . . . . . 18
         4.1.2.5.  Crash of an application by plug-in . . . . . . . . 18
         4.1.2.6.  Happy Eyeball implementation with turn-on/off
                   switch . . . . . . . . . . . . . . . . . . . . . . 19
         4.1.2.7.  Different behavior among OSes on MTU handling  . . 19
     4.2.  MTU and NAT Traversal Tests for Network Games  . . . . . . 20
       4.2.1.  Between a Client and the STUN Server . . . . . . . . . 20
       4.2.2.  Between Clients with NAT . . . . . . . . . . . . . . . 24
     4.3.  Analysis of inappropriate authoritative servers from
           DNS64 Log  . . . . . . . . . . . . . . . . . . . . . . . . 24
   5.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 26
     5.1.  Dependency between IPv4 and IPv6 address configuration . . 26
     5.2.  PMTUD, MTU mismatch problems and NAT behavior problems . . 27
     5.3.  Workaround for DNS64 problems  . . . . . . . . . . . . . . 27
       5.3.1.  Workaround for illegal NameError . . . . . . . . . . . 27
       5.3.2.  Workdaround for lame delegation  . . . . . . . . . . . 27
   6.  Conclusion and Future Work . . . . . . . . . . . . . . . . . . 28
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 29



Hazeyama, et al.       Expires September 14, 2012               [Page 3]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32

















































Hazeyama, et al.       Expires September 14, 2012               [Page 4]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


1.  Introduction

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

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

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

1.1.1.  Summary of the 1st experiment

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

1.1.2.  Abstract of the 2nd experiment

   According to the experiences on the 1st experiment, the 2nd
   experiment was conducted from March 5th to March 8th, 2012 in
   Matsushiro Royal Hotel, the same hotel of the 1st experiment. 171
   participants joined this 2nd experiment, most of them were engineers
   or academic people.  The settings of the core network in the 2nd
   experiment was same as the 1st experiment.  In the 1st experiment, a
   commercial IPv6 network service was employed as a backbone network,



Hazeyama, et al.       Expires September 14, 2012               [Page 5]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   in other word, we did evaluate the availability of commercial IPv6
   network services from the view of home users.  Therefore, the
   evaluation target of the 2nd experiment was planned as living in
   commercial IPv6 networks with IPv4 / IPv6 translation technologies or
   IPv4 / IPv6 translation services.

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

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

   Along with the DNS64/NAT64 translation service, for aiming to
   evaluate more practical approaches on the current commercial
   environments, we tested three IPv4 services over IPv6 networks, 4RD,
   SA46T and 464XLAT.  We mainly served seven IP networks to
   participants by combination of those networks and translation
   services, that is, native IPoE with DNS64/NAT64, native PPPoE with
   DNS64/NAT64, 4RD on both IPoE and PPPoE, 464XLAT on both IPoE and
   PPPoE, SA46T on PPPoE.

   Three evaluations were mainly conducted by the evaluation team, i)
   user survey about the availability of each network through face to
   face interview, ii) analysis of DNS behaviors to grasp inappropriate
   behaviors mentioned in [RFC4074], iii) availability test of VPN
   applications to analyze MTU problems or to grasp whether an
   unavailability of VPN applications was intentional one due to the
   specification of a translation technology or not.  Also, Konami
   Digital Entertainment (KDE) joined in this experiment, and evaluated
   NAT/Firewall traversal testing on each IPv6 network or each
   translator service from the view of commercial (P2P) Network Game
   services.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Hazeyama, et al.       Expires September 14, 2012               [Page 6]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Technology and Terminology

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

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

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

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

   "4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure
   defined in [I-D.draft-murakami-softwire-4rd].

   "464XLAT" refers to Combination of Stateful and Stateless Translation
   defined in [I-D.draft-ietf-v6ops-464xlat].


3.  Network and Experiment Setup

   The WIDE camp spring 2012 was held at Matsushiro Royal Hotel in
   Nagano Prefecture of Japan, the same place of the 1st experiment,
   from March 5th to March 8th, 2012.  Figure Figure 1 shows the
   overview of the test topology on the 2nd experiment, and Figure
   Figure 2 and Figure Figure 3 represent details of the network in
   Matsushiro Royal Hotel.

   We, WIDE Project, set up the same IPv6 only network of the 1st
   experiment held in September 2011 as a core network, dual stack and
   SA46T on PPPoE through IPv6 L2TP tunnel with using WIDE backbone's
   address blocks.  Together with these core network settings by WIDE
   Project, we added actual use cases of commercial IPv6 networks and
   translation services with supports from a Japanese Access Carrier
   (NTT-East), an ISP (IIJ), an IX (JPIX), a VNE (Internet MultiFeed), a



Hazeyama, et al.       Expires September 14, 2012               [Page 7]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   network equipment vendor (NEC AccessTechnica) and a SIer (NTT
   Advanced Technology).


       +-----------------------------------------------+
       |                  The Internet                 |
       +-----------------------------------------------+
                |  |   |                      |
      +------+  |  |   |                      |
      | PLAT |  |  |   |                      |
      +------+  |  |   |                      |
          |     |  |   |                      |
      +------+  |  |   |                      |
      | JPIX |--+  |   |                      |
      +------+     |   |                      |
                   |   |                      |
        +-----------+  |                 +------------+
        | IIJ (ISP) |  |                 | WIDE (ISP) |
        +-----------+  |                 +------------+
          |      |     |                   |         |
    +------+   +-----------+               |        +-------+
    |4RD-BR|   |MFeed (VNE)|             +-------+  | SA46T |
    +------+   +-----------+             |v6 L2TP|  +-------+
                         |               +-------+
                   +--------------------------------+
                   |     NTT NGNv6 (Access Line)    |
                   +--------------------------------+
                                  |
    +------------------------------------------------------------+
    | IPv6 test networks                                         |
    |+-PD Router-+ +---4RD-CE---+ +----CLAT----+ +---- L2TP ----+|
    || IPv6 only | |    4RD     | |  464XLAT   | | SA46T | dual ||
    ||-----------| |------------| |------------| |--------------||
    ||IPoE |PPPoE| |IPoE | PPPoE| |IPoE | PPPoE| |    PPPoE     ||
    |+-----------+ +------------+ +------------+ +--------------+|
    +------------------------------------------------------------+
                                    |
    +------------------------------------------------------------+
    |      Wi-fi Access (CISCO  Layer 2 mesh, 11b/g/n Wi-fi)     |
    +------------------------------------------------------------+

                 Over view of the 2nd experiment topology

                                 Figure 1







Hazeyama, et al.       Expires September 14, 2012               [Page 8]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


                       +----------------+
                       |    NTT NGNv6   |
                       +----------------+
                               |(NGN IPoE Access Service)
                          +--------+
                          | ONU-48 | 2409:150:8000::/48
                          +--------+
                               |
    +--Flets IPv6 -------------+-----------------------------+
                               |
                               |(v6)
                        +-------------+
        +---------------|   PD Router |-------------+
        |               +-------------+             |
        |                      |(v6)                |
        | +-------+        +--------+           +--------+
        | | DHCP6 |        |  CLAT  |           | 4RD-CE |
        | +-------+        +--------+           +--------+
        |   |                  |                    |
        |   |                  |                    |
        |   |                  |                    |
    +- global v6 -+      +- global v6 -+      +- private v4-+
        no ipv4             private v4             no v6
        with                  with                 with
      NAT64/DNS64        DNS v4/ v6 Proxy       DNSv4 proxy
      on the camp           of CLAT             of 4RD-CE

                The Test Topology on NTT NGNv6 IPoE service

                                 Figure 2





















Hazeyama, et al.       Expires September 14, 2012               [Page 9]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


                    +-------------------+
                    | IIJ PPPoE Service |
                    +-------------------+
                           | (NGN PPPoE Access Service)
                       +--------+
                       | ONU-56 |
                       +--------+
                           |
    +--IIJ PPPoE IPv6 -----+---------------- 2001:240:2002:6d00::/56
                           |(v6)
                     +-------------+       (v6)       +---------+
                     | PPPoE Client|------------------| v6 L2TP |
        +------------| & PD router |---------+        +---------+
        |            +-------------+         |           |
        |(v6)              |(v6)           |(v6)         |(dual)
        | +-------+    +--------+      +--------+   +--------+
        | | DHCP6 |    |  CLAT  |      | 4RD-CE |   | router |---+
        | +-------+    +--------+      +--------+   +--------+   |
        |   |              |(dual)         |(v4)       |  +-dual stack-+
        |   |              |               |           |      (WIDE)
        |   |              |               |           | +-------+
        |   |              |               |           | | SA46T |
    +- global v6 -+  +- global v6 -+ +- private v4-+   | +-------+
        no v4           private v4       no v6         |    |
         with             with           with          |    | +-----+
      DNS64/NAT64     DNS v4/v6Proxy  DNS v4 Proxy     |    | |DHCP4|
      on the camp        of CLAT       of 4RD-CE       |    | +-----+
                                                       |    |    |
                                                   +-- global v4 --+
                                                         no v6
                                                       with DNS4
                                                      on the camp


               The Test Topology on NTT NGNv6 PPPoE service

                                 Figure 3

3.1.  IPv6 networks

   The same IPv6 network of the 1st experiment was achieved as a core
   network in the 2nd experiment, that is, a WIDE backbone IPv6 network
   through IPv6 L2TP over the NTT NGNv6 PPPoE service.  DNS v4, DNSv6,
   DNS64, NAT64 and web servers for local information were settled in
   the server segment of this core network by dual stack fashion with
   DNS load balancing.  DHCP4, DHCP6, Radius, CISCO's WLC and WCS, STUN
   and TURN servers were also settled in this server segment.  IPv6
   connectivity with DNS64/NAT64 was provided through other two



Hazeyama, et al.       Expires September 14, 2012              [Page 10]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   experiments, LISP/VXLAN experiment and OSLR based Layer 3 mesh wi-fi
   experiment.  As a backup plan, we prepared a dual stack environment
   for users in wired access.  Of course, this dual stack was able to be
   served in wireless access.  Actually, we provided this dual stack
   network to participants through layer 2 mesh wi-fi during the closing
   session in March 8th.

   We also constructed two IPv6 networks based on commercial IPv6
   services which are available by home users in Japan.  One was 2409:
   150:8000::/48 IPv6 network through NTT NGNv6 IPoE method (labeled
   native IPoE), the other was 2001:240:2002:6d00::/56 IPv6 network
   through NTT NGNv6 PPPoE method (named native PPPoE).  Basically,
   these two IPv6 networks were pure IPv6 networks, therefore, we served
   them with the DNS64/NAT64 service on the camp core network through
   DNS load balancing by F5 Big IP.  NTT Advanced Technology supported
   to set up this DNS load balancing.

   On the evening of 3rd day (March 7th), we prepared a rouge AP to test
   DoS attacks to IPv6 clients.  The rogue AP did not provide any
   Internet connectivity, and attacked wi-fi clients by massive RA
   announcement.

3.2.  IPv4 networks

   Three IPv4 network services were provided in the 2nd experiment,
   SA46T, 4RD and 464XLAT.  Different from the 1st experiment, both
   SA46T and 4RD were provided as pure IPv4 network services in this 2nd
   experiment.

   SA46T provided a global IPv4 network of WIDE backbone with three
   SA46T implementations and with DNS v4 service of the core network in
   the camp.  The SA46T gateway on the WIDE backbone was Keio university
   implementation (SA46T-KO), on the other hand, two implementations of
   SA46T by Fujitsu group (SA46T-FA and SA46T-FK) were employed in the
   Matsushiro Royal Hotel.

   4RD served a private IPv4 network where the 4RD-BR was settled on an
   experimental network of IIJ.  The 4RD-CE played NAPT and DNS v4
   proxy.  Both 4RD-BR and 4RD-CE were IIJ SEIL router implementations
   [SEIL].  The 4RD network was operated by IIJ.

   464 XLAT, which is now under a field trial of JPIX, was operated by
   JPIX and NEC AccessTechnica. 464XLAT provided a pure global IPv6
   network service and a private IPv4 NAT service.  CLAT, which is a
   client side translator of 464XLAT, ran as IPv6 gateway, a stateless
   translator [RFC6145], and DNS v4/v6 proxy.

   Each transition technology has limitation on available protocols,



Hazeyama, et al.       Expires September 14, 2012              [Page 11]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   fragmentation support, and so on.  One of purposes of this 2nd
   experiment was to grasp these limitations and reasons of each
   limitation.

3.3.  DNS Settings

   Table Table 1 shows the DNS settings of each network.  On the core
   network, F5 Big IP was placed as a DNS load balancer (203.178.159.58,
   2001:200:0:ff60::58), which simply forwarded AAAA queries from native
   IPoE, native PPPoE and dual stack to DNS64 (2001:200:0:ff60::6),
   transferred A queries under the SA46T service on the camp to DNS4
   (203.178.159.2) and redirected queries from the out of the camp to
   nons.wide.ad.jp.  DNS4, DNS6 and DNS64 ran on a same physical server
   on the server segment.

   ISC BIND was employed as the DNS64.  The DNS64 was configured as a
   just forward only server which did not send recursive queries by
   itself, that is, the DNS64 server referred other DNS recursive
   resolver.  We also prepared ISC BIND and NLNetLab Unbound for
   recursive resolvers to compare error messages related with [RFC4074].
   The recursive resolver referred from the DNS64 was changed from ISC
   BIND server to Unbound server at the midnight of March 5th because
   the error check rules of Unbound server was more loose than that of
   ISC BIND, thus, we chose the Unbound server to reduce unnecessary
   error messages on syslog.

   Basically, DNS settings were transferred to users devices through
   DHCP4 or DHCP6.  When a user's device did not have DHCP6 capability
   such as Mac OS X Snow Leopard or older, we let the user to set 2001:
   200:0:ff60::58 or 2001:200:0:ff60::6 manually.

   In 4RD segments and 464XLAT segments, CE routers ran as DNS proxy to
   name servers on VNE or ISP, or the open name server of Google.


















Hazeyama, et al.       Expires September 14, 2012              [Page 12]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   +----------------------------+--------------------------------------+
   |           Network          |             DNS settings             |
   +----------------------------+--------------------------------------+
   |     Dual Stack, Manual     |  203.178.159.53, 2001:200:0:ff60::53 |
   |   settings for older OSes  |          (DNS load balance)          |
   | -------------------------- | ------------------------------------ |
   |            LISP            |      2001:200:0:ff60::6 (DNS64)      |
   | -------------------------- | ------------------------------------ |
   |           L3 mesh          |      2001:200:0:ff60::6 (DNS64)      |
   | -------------------------- | ------------------------------------ |
   |         native IPoE        |     2001:200:0:ff60::53 (DNS load    |
   |                            |               balance)               |
   | -------------------------- | ------------------------------------ |
   |        native PPPoE        |     2001:200:0:ff60::53 (DNS load    |
   |                            |               balance)               |
   | -------------------------- | ------------------------------------ |
   | SA46T (SA46T-FA, SA46T-FK) |   203.178.159.53 (DNS load balance)  |
   | -------------------------- | ------------------------------------ |
   |  4RD (4RD/IPoE, 4RD/PPPoE) |        210.130.1.1 (via proxy)       |
   | -------------------------- | ------------------------------------ |
   |        464XLAT/IPoE        |     2404:1a8:7f01:b::3 (primary),    |
   |                            |   2001:4860:4860::8888 (secondary)   |
   | -------------------------- | ------------------------------------ |
   |       464XLAT/PPPPoE       |        2001:240::13 (primary),       |
   |                            |   2001:4860:4860::8888 (secondary)   |
   +----------------------------+--------------------------------------+

                           Table 1: DNS settings

3.4.  NAT64 Settings

   We prepared two NAT64 implementations in the core network.  One was
   linuxnat64 which ran on the same physical server of DNS64.  The other
   was F5 Big IP's NAT64 function. linuxnat64 based NAT64 service was
   provided from 10:00 of March 5th.  F5 Big IP's NAT64 function was
   introduced from 22:00 of March 7th.

3.5.  Wireless networks

   Eight networks (native IPoE, native PPPoE, 4RD/IPoE, 4RD/PPPoE,
   464XLAT/IPoE, 464XLAT/PPPoE, SA46T-FA, SA46T-KF) were served to
   participants of the camp through CISCO L2 mesh Wi-Fi with WPA TKIP.
   Table Table 2 shows the served networks in each time slot.  The
   evening of March 7th (From 18:00 of March 7th to 5:00 of March 8th),
   we arranged networks for two additional tests.  One was fallback by
   closed IPv6 network of NTT NGNv6 in the 4RD/PPPoE environment.  The
   other was 4RD/IPoE served through IEEE 11b wi-fi for commercial
   portable game devices (Nintendo DS / 3DS, Sony PSP / PSVita).



Hazeyama, et al.       Expires September 14, 2012              [Page 13]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   As mention above, the NOC team also had other two experiments in
   wireless networks, LISP/VXLAN experiment on CISCO managed Wi-Fi and
   of OSLR based layer 3 mesh wi-fi experiment.  Both networks served
   IPv6 only network with DNS64/NAT64 services of the camp.  Due to the
   out of scope on this document, we do not explain the details of other
   two experiments.

   +------------+--------------+--------------+---------------+--------+
   |  Time Slot |    ESSID 1   |    ESSID 2   |    ESSID 3    |  ESSID |
   |            |              |              |               |    4   |
   +------------+--------------+--------------+---------------+--------+
   | 13:00 Mar. | 464XLAT/IPoE |   4RD/IPoE   |  native IPoE  |    -   |
   |   5th to   |              |              |               |        |
   | 17:30 Mar. |              |              |               |        |
   |     5th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   | 18:00 Mar. |  native IPoE | native PPPoE |   4RD/PPPoE   |    -   |
   |   5th to   |              |              |               |        |
   | 12:00 Mar. |              |              |               |        |
   |     6th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   | 12:30 Mar. |    L3 mesh   |   SA46T-FA   | 464XLAT/PPPoE | native |
   |   6th to   |    (IPv6)    |              |               |  IPoE  |
   | 17:30 Mar. |              |              |               |        |
   |     6th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   | 18:00 Mar. | native PPPoE | 464XLAT/IPoE |    SA46T-FK   |    -   |
   |   6th to   |              |              |               |        |
   | 12:00 Mar. |              |              |               |        |
   |     7th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   | 12:30 Mar. | native PPPoE |   4RD/IPoE   |  native IPoE  |    -   |
   |   7th to   |              |              |               |        |
   | 17:30 Mar. |              |              |               |        |
   |     7th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   | 18:00 Mar. |   4RD/PPPoE  |  4RD/IPoE on |  native IPoE  |  rogue |
   |   7th to   |  with closed |   IEEE 11b   |               |        |
   |  5:00 Mar. |     IPv6     |              |               |        |
   |     8th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   |  5:00 Mar. |  dual stack  |       -      |       -       |    -   |
   |   8th to   |    (WIDE)    |              |               |        |
   | 12:00 Mar. |              |              |               |        |
   |     8th    |              |              |               |        |
   | ---------- | ------------ | ------------ | ------------- | ------ |
   +------------+--------------+--------------+---------------+--------+




Hazeyama, et al.       Expires September 14, 2012              [Page 14]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


     Table 2: Time Slot of served networks through layer 2 mesh Wi-Fi

3.6.  Settings for MTU and NAT / Firewall Traversal Tests for commercial
      (P2P) Network Games

   Evaluating MTU and NAT / Firewall Traversal Tests on each test
   network for commercial (P2P) Network Games, Konami Digital
   Entertainment (KDE) experiment team placed STUN [RFC5389] and TURN
   [RFC5766] servers in the server segment of the camp core network.
   KDE prepared test clients, for testing IPv4 NAT/Firewall traversal
   from the view of consumer games.  Test clients accessed to STUN /
   TURN servers and evaluated whether each network satisfied
   requirements from network games or not.  The evaluation results will
   be explained in section 4 of this document.


4.  Experiences from the Experiments

4.1.  User Survey by face-to-face interview

   Here, we reports results of user survey.  The user Survey was
   conducted in face-to-face interview fashion.  We interviewed 166
   participants about brought devices and their OSes.  We also asked
   about the availability of networks, troubles or inconveniences.

   Because implementations of 4RD, 464XLAT, SA46T were designed along
   with performance specifications for home users, maximum users on each
   implementation without heavy load were around 50 clients to 80
   clients.  Participants were likely to move another network when they
   felt congestion or heavy load.  Therefore, number of users on each
   network was balanced to each other, around 50 to 80.

4.1.1.  Client Profile

   At the 2nd experiment, 297 unique devices were identified from 166
   participants.  This shows one participants brought two or more
   devices.  Typical participants took a normal personal computer and a
   smart-phone or a similar personal device such as iPod touch, iPad,
   Kindle, portable game devices.  Table.  Table 3 shows distributions
   of Devices.  Table.  Table 4 shows distributions of OSes.  We also
   profiled applications on these devices.  We looked over lots of
   applications but some of them had problems due to lack of
   applicability to IPv6 and its network characteristic.  All
   problematic cases were as same as reported in the 1st camp.  The
   worst case was that we saw an application was crashed.  The lack of
   applicability to IPv6 can be summarized as bellow.  Any kind of VPN
   has a propensity for getting into accidents.




Hazeyama, et al.       Expires September 14, 2012              [Page 15]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


          +-------------------+--------------------------------+
          |      Devices      | # of participants (percentage) |
          +-------------------+--------------------------------+
          | Personal Computer |          140 (47.1 %)          |
          | ----------------- | ------------------------------ |
          |     Tablet PC     |           23 (7.7 %)           |
          | ----------------- | ------------------------------ |
          |    Smart Phone    |          114 (38.4 %)          |
          | ----------------- | ------------------------------ |
          |    Game Devices   |           19 (6.4 %)           |
          | ----------------- | ------------------------------ |
          |       Others      |            1 (0.3 %)           |
          +-------------------+--------------------------------+

           Table 3: The distributions of devices of participants

         +---------------------------+---------------------------+
         |             OS            | # of devices (percentage) |
         +---------------------------+---------------------------+
         |          Android          |        37 (12.5 %)        |
         | ------------------------- | ------------------------- |
         |        Android 2.2        |         2 (9.7 %)         |
         | ------------------------- | ------------------------- |
         |        Android 2.3        |         3 (1.0 %)         |
         | ------------------------- | ------------------------- |
         |       Android 2.3.4       |         2 (0.7 %)         |
         | ------------------------- | ------------------------- |
         |       Android 4.0.2       |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |       Android 4.0.3       |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |         Arch Linux        |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |         blackberry        |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |           CentOS          |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |           Debian          |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |          FreeBSD          |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |        iOS 4.3.2 JB       |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |          iPad iOS         |         21 (7.1 %)        |
         | ------------------------- | ------------------------- |
         |         iPhone iOS        |        59 (19.9 %)        |
         | ------------------------- | ------------------------- |
         |       iPod Touch iOS      |         11 (3.7 %)        |



Hazeyama, et al.       Expires September 14, 2012              [Page 16]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


         | ------------------------- | ------------------------- |
         |           Kindle          |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |   Linux Open WRT 2.7.39   |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |       Mac OS X Lion       |        48 (16.2 %)        |
         | ------------------------- | ------------------------- |
         |   Mac OS X Snow Leopard   |        31 (10.4 %)        |
         | ------------------------- | ------------------------- |
         |         NetBSD 5.1        |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |         Nokia 5800        |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |            PSP            |         2 (0.7 %)         |
         | ------------------------- | ------------------------- |
         |          PS Vita          |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |           Ubuntu          |         4 (1.3 %)         |
         | ------------------------- | ------------------------- |
         |        WiMAX Router       |         1 (0.3 %)         |
         | ------------------------- | ------------------------- |
         |       Windows Vista       |         4 (1.3 %)         |
         | ------------------------- | ------------------------- |
         |         Windows XP        |         11 (3.7 %)        |
         | ------------------------- | ------------------------- |
         |         Windows 7         |        35 (11.8 %)        |
         | ------------------------- | ------------------------- |
         |       Windows Mobile      |         3 (1.0 %)         |
         | ------------------------- | ------------------------- |
         | Nintendo DS / 3DS (0.3 %) |         3 (1.0 %)         |
         +---------------------------+---------------------------+

     Table 4: The distributions of Operating Systems on participants'
                                  devices

4.1.2.  Reported Troubles

   Here, we explain reported troubles or inconveniences of participants
   on network connectivity.  There troubles / inconveniences were
   reported by participants through face-to-face interview or comments
   on a wiki.

4.1.2.1.  Failure of IPv6 neighbor discovery due to the on-link
          assumption of IPv4 network

   In the IPv6 single stack LAN, although 169.254/16 IPv4 Link Local
   Address[RFC3927] was assigned to an interface, some devices tried to
   get IPv4 address by DHCP4 and failed IPv6 neighbor discovery due to



Hazeyama, et al.       Expires September 14, 2012              [Page 17]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   the DHCP4 failure.  In this case, the IPv6 network was never
   available by the participant, therefore, they were likely to move to
   another network where an IPv4 private/global address was assigned.
   That is, IPv4 DHCP Discovery along with on-link assumption of IPv4
   network blocked IPv6 Neighbor Discovery.

   The similar harmful behavior on IPv6 Neighbor Discovery along with
   on-link assumption in IPv4 only network has been described in
   [RFC4943].  We need further evaluation and discussion on this IPv4
   case.

4.1.2.2.  Locked out IPv6 by vendor

   There were two devices which were made different hardware but
   equipped same OS with same version.  These two devices were also
   subscribed with a same mobile company and had a same behavior to the
   IPv4.  However, the one can get IPv6 address over WiFi network and
   the other can not do so.  The OS was announced that has IPv6
   capability from the OS vendor.  In this case, we suspected that the
   hardware vendor may lock out IPv6 function.  We should have further
   examinations on this trouble.

4.1.2.3.  Inappropriate selection of DNS resolvers

   We observed inappropriate DNS resolver settings on resolve.conf of
   several clients, for example, the DNS resolver address was never
   reached from a client without translators.  These inappropriate DNS
   resolver settings were caused by careless mistake on DHCP6 and RA
   settings due to lack of understanding on appropriate name servers on
   a network.  Once this trouble occurred, it was hard for users to
   comprehend and to deal with it.  If the ULA (Unique Local global
   unicast Address [RFC4193]) was used, it might be getting more
   complicated.

4.1.2.4.   Previous configuration lived after moving to another WiFi
          network

   With some of latest OSes, participants had a trouble on network
   configuration in the client PC.  The trouble of network configuration
   would be caused that the OS kept the previous network information and
   could not renew after getting into another WiFi network.  This
   trouble was hard to be solved, when the trouble on mis-configuration
   of name servers (section Section 4.1.2.3) occurred at the same time.

4.1.2.5.  Crash of an application by plug-in

   An IPv4 depended plugin crashed an application.  Unawareness of dual
   stack for application programmers may occur serious problems before



Hazeyama, et al.       Expires September 14, 2012              [Page 18]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   IPv6 deployment.  It is more important to share what is dual stack
   network and functions for dual stack communications.

4.1.2.6.  Happy Eyeball implementation with turn-on/off switch

   Happy eyeball implementation which enables faster communication with
   IPv4 Internet is very effective if the IPv6 network is not available
   or the IPv6 network becomes slow down than an IPv4 network.  However,
   when an IPv6 network is faster than an IPv4 network, the Happy
   eyeball function may decrease the performance of web browsing.
   Therefore, some implementations of Happy Eyeball equip turn-on/off
   switch.

   However, such turn-on/off switch usually requires parameter settings
   and parameter settings are difficult.  Actually, network engineers in
   the 2nd experiment had difficulty on parameter tuning of Happy
   Eyeball.  Network engineers on the 2nd experiment worried about that
   average or novice users could not use well current turn-on/off switch
   implementation of Happy Eyeball.

4.1.2.7.  Different behavior among OSes on MTU handling

   In the 1st experiment, several participant claimed download of big
   data did not work through PPTP access over SA46T. To verify the cause
   of this problem, we evaluated communications to servers through PPTP
   access over SA46T by Windows 7 and Mac OS Lion in this 2nd
   experiment.  Test servers were a CISCO UCS server to download remote
   KVM java program and a linux server accessed by ssh.  Then, the data
   transfer on Windows 7 worked well both on access to the CISCO UCS
   server and on the linux server.  On the other hand, that on Mac OS
   Lion stopped in a few minutes neither the CISCO UCS server nor on the
   linux server.

   To clarify that whether the difference derived from MTU size or not,
   we evaluate ping program on each OS with changing payload size and DF
   bit value.  In Windows 7, ``ping -l 1500'' worked and ``ping -l 1500
   -f'' did not work.  On the other hand, in Mac OS Lion, ``ping -s ''
   stopped around from 1411 to 1416.  This result implies that MTU /
   fragmentation handling between Windows 7 and Mac OS Lion are
   different, and that MTU / fragmentation handling of Mac OS Lion may
   not be suit to IPv4 / IPv6 transition situation.

   We could not determine root cause of this trouble during the 2nd
   experiment, because of SA46T fragment functions.  Three SA46T
   implementations were employed in 2nd experiment and they had
   different packet fragmentation support shown in section Section 4.2.
   Therefore, we could not remove the influence from lack of
   fragmentation support of one of SA46T implementation.  We have to



Hazeyama, et al.       Expires September 14, 2012              [Page 19]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   verify difference of behaviors on packet fragmentation among OSes
   with further experiments.

4.2.  MTU and NAT Traversal Tests for Network Games

   Here, we explain the result of MTU and NAT Traversal Tests by KDE
   experiment team.  The test patterns were designed according to
   [RFC4787] as follows;

   o  Address and Port Mapping Behavior

   o  Port Assignment Behavior

   o  Filtering Behavior

   o  Hairpinning Behavior

   o  Fragmentation of Outgoing Packets

   o  Receiving Fragmented Packets

   These items were tested by KDE's test clients through STUN protocols
   defined in [RFC5389] and in [RFC5780].  Clients sent UDP packets to
   the STUN server along with test scenarios.

4.2.1.  Between a Client and the STUN Server

   Table Table 5 shows test items by a client.  Table Table 6, Table
   Table 7, Table Table 8 and Table Table 9 shows MTU and NAT Traversal
   test results on each network.

   The SA46T results in Table Table 8 and Table Table 9 derived from the
   difference among implementations on fragment support function.


















Hazeyama, et al.       Expires September 14, 2012              [Page 20]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   +------------------+------------------------------------------------+
   |     Elements     |                   Definition                   |
   +------------------+------------------------------------------------+
   |        NAT       |          Exist: NAT exists, - : no NAT         |
   | ---------------- | ---------------------------------------------- |
   |      Mapping     | Good or Bad : Good / Bad Behavior for P2P Game |
   | ---------------- | ---------------------------------------------- |
   |     Filtering    | Good or Bad : Good / Bad Behavior for P2P Game |
   | ---------------- | ---------------------------------------------- |
   |        RTT       |             Round Trip Time (msec.)            |
   | ---------------- | ---------------------------------------------- |
   |   MTU size from  |                   size (byte)                  |
   | client to server |                                                |
   | ---------------- | ---------------------------------------------- |
   |   Fragmentation  |  OK or NG : whether a big packet (DF=0) can be |
   |  from client to  |      sent from a client to the server with     |
   |      server      |              fragmentation or not.             |
   | ---------------- | ---------------------------------------------- |
   |   MTU size from  |                   size (byte)                  |
   | server to client |                                                |
   | ---------------- | ---------------------------------------------- |
   |   Fragmentation  | YES or NO : whether a big packet (DF=0) can be |
   |  from server to  |      sent from the server to a client with     |
   |      client      |              fragmentation or not.             |
   +------------------+------------------------------------------------+

   Table 5: Test Elements of NAT, Mapping, Filtering ( RFC 4787 ) / RTT
                                   / MTU























Hazeyama, et al.       Expires September 14, 2012              [Page 21]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


        +-----------------+-------------------+------------------+
        |     Elements    | native PPPoE (v6) | native IPoE (v6) |
        +-----------------+-------------------+------------------+
        |       NAT       |         -         |         -        |
        | --------------- | ----------------- | ---------------- |
        |     Mapping     |         -         |         -        |
        | --------------- | ----------------- | ---------------- |
        |    Filtering    |         -         |         -        |
        | --------------- | ----------------- | ---------------- |
        |       RTT       |        117        |        75        |
        | --------------- | ----------------- | ---------------- |
        | MTU size C => S |        1452       |       1500       |
        | --------------- | ----------------- | ---------------- |
        |   Frag. C => S  |        YES        |        YES       |
        | --------------- | ----------------- | ---------------- |
        | MTU size S => C |        1500       |       1500       |
        | --------------- | ----------------- | ---------------- |
        |   Frag. S => C  |        YES        |        YES       |
        +-----------------+-------------------+------------------+

   Table 6: NAT Traversal Test Results between a Client and STUN Server
                               (global IPv6)

        +-----------------+-------------------+------------------+
        |     Elements    |   4RD/PPPoE (v4)  |   4RD/IPoE (v4)  |
        +-----------------+-------------------+------------------+
        |       NAT       |       Exist       |       Exist      |
        | --------------- | ----------------- | ---------------- |
        |     Mapping     |        Bad        |       Good       |
        | --------------- | ----------------- | ---------------- |
        |    Filtering    |        Good       |       Good       |
        | --------------- | ----------------- | ---------------- |
        |       RTT       |        156        |        323       |
        | --------------- | ----------------- | ---------------- |
        | MTU size C => S |        1452       |       1452       |
        | --------------- | ----------------- | ---------------- |
        |   Frag. C => S  |         NO        |        NO        |
        | --------------- | ----------------- | ---------------- |
        | MTU size S => C |        1280       |       1452       |
        | --------------- | ----------------- | ---------------- |
        |   Frag. S => C  |        YES        |        YES       |
        +-----------------+-------------------+------------------+

   Table 7: NAT Traversal Test Results between a Client and STUN Server
                                  on 4RD






Hazeyama, et al.       Expires September 14, 2012              [Page 22]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


       +-----------------+--------------------+-------------------+
       |     Elements    | 464XLAT/PPPoE (v4) | 464XLAT/IPoE (v4) |
       +-----------------+--------------------+-------------------+
       |       NAT       |        Exist       |       Exist       |
       | --------------- |  ----------------- |  ---------------- |
       |     Mapping     |        Good        |        Good       |
       | --------------- |  ----------------- |  ---------------- |
       |    Filtering    |        Good        |        Good       |
       | --------------- |  ----------------- |  ---------------- |
       |       RTT       |         119        |        464        |
       | --------------- |  ----------------- |  ---------------- |
       | MTU size C => S |        1260        |        1476       |
       | --------------- |  ----------------- |  ---------------- |
       |   Frag. C => S  |         YES        |        YES        |
       | --------------- |  ----------------- |  ---------------- |
       | MTU size S => C |        1260        |        1480       |
       | --------------- |  ----------------- |  ---------------- |
       |   Frag. S => C  |         YES        |        YES        |
       +-----------------+--------------------+-------------------+

   Table 8: NAT Traversal Test Results between a Client and STUN Server
                                on 464XLAT

   +-----------------+------------------------+------------------------+
   |     Elements    |      SA46T-FA (v4)     |      SA46T-FK (v4)     |
   +-----------------+------------------------+------------------------+
   |       NAT       |            -           |            -           |
   | --------------- | ---------------------- | ---------------------- |
   |     Mapping     |            -           |            -           |
   | --------------- | ---------------------- | ---------------------- |
   |    Filtering    |            -           |            -           |
   | --------------- | ---------------------- | ---------------------- |
   |       RTT       |           112          |           76           |
   | --------------- | ---------------------- | ---------------------- |
   | MTU size C => S |          1460          |          1460          |
   | --------------- | ---------------------- | ---------------------- |
   |   Frag. C => S  |           YES          |    NO (lack of frag.   |
   |                 |                        |   func. on SA46T-FK)   |
   | --------------- | ---------------------- | ---------------------- |
   | MTU size S => C |    NO (lack of frag.   |    NO (lack of frag.   |
   |                 |   func. on SA46T-KO)   |   func. on SA46T-KO)   |
   | --------------- | ---------------------- | ---------------------- |
   |   Frag. S => C  |  NO (due to SA46T-KO)  |  NO (due to SA46T-KO)  |
   +-----------------+------------------------+------------------------+

   Table 9: NAT Traversal Test Results between a Client and STUN Server
                                 on SA46T




Hazeyama, et al.       Expires September 14, 2012              [Page 23]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


4.2.2.  Between Clients with NAT

   +---------------+-------------+-------------------------------------+
   |    Network    |   Protocol  |             Connectivity            |
   +---------------+-------------+-------------------------------------+
   |  native PPPoE |     IPv6    |            Good (no NAT)            |
   |  -----------  | ----------- |             -----------             |
   |  native IPoE  |     IPv6    |            Good (no NAT)            |
   |  -----------  | ----------- | ----------------------------------- |
   |   4RD/PPPoE   |     IPv4    |   Bad (Address and Port dependent   |
   |               |             |               mapping)              |
   |  -----------  | ----------- | ----------------------------------- |
   |    4RD/IPoE   |     IPv4    |         Bad (no hairpinning)        |
   |  -----------  | ----------- | ----------------------------------- |
   | 464XLAT/PPPoE |     IPv4    |         Bad (no hairpinning)        |
   |  -----------  | ----------- | ----------------------------------- |
   |  464XLAT/IPoE |     IPv4    |         Bad (no hairpinning)        |
   |  -----------  | ----------- | ----------------------------------- |
   |    SA46T-FA   |     IPv4    |            Good (no NAT)            |
   |  -----------  | ----------- | ----------------------------------- |
   |    SA46T-FK   |     IPv4    |            Good (no NAT)            |
   +---------------+-------------+-------------------------------------+

      Table 10: P2P connectivity between Clients on each IPv6 or IPv4
                                  network

4.3.  Analysis of inappropriate authoritative servers from DNS64 Log

   We analyzed DNS64 log to grasp inappropriate authoritative servers
   for DNS64.  DNS64 will fall back to A record query when an
   authoritative server returns AAAA query with ``NOERROR ANSWER=0''.
   DNS64 fails to fallback A record query when an authoritative server
   returns inappropriate AAAA record mentioned in [RFC4074].  Also,
   [RFC6147] says

      Any other RCODE is treated as though the RCODE were 0 and the
      answer section were empty.  This is because of the large number of
      different responses from deployed name servers when they receive
      AAAA queries without a AAAA record being available.  Note that
      this means, for practical purposes, that several different classes
      of error in the DNS are all treated as though a AAAA record is not
      available for that owner name.

      It is important to note that, as of this writing, some servers
      respond with RCODE=3 to a AAAA query even if there is an A record
      available for that owner name.  Those servers are in clear
      violation of the meaning of RCODE 3, and it is expected that they
      will decline in use as IPv6 deployment increases.



Hazeyama, et al.       Expires September 14, 2012              [Page 24]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   In the 2nd experiment, we analyzed that distributions of error
   messages of AAAA queries, and that whether number of error messages
   are changed by DNS implementations or not.

   The name server settings of the camp were as follows;

      F5 BIG-IP forwarded queries to DNS64 server except
      ``www.camp.wide.ad.jp''.

      DNS64 server only forwarded queries to Unbound/BIND resolver and
      did not do any iterative queries by itself

      We have changed target resolver from bind server to unbound server
      at midnight on March 5th

   We analyzed DNS64's error messages recorded in March 5th when DNS64
   forwarded queries to the BIND resolver.  Table Table 11 shows number
   of unique authoritative servers in each error message.  Most error
   messages of BIND resolver were FormError.  Comparing differences
   between implementations, we recheck FormError authoritative servers
   by Unbound.  The result is shown in Table Table 12.  According to
   these result, BIND is more restrict to ``bogus'' response than
   Unbound.  For example, BIND was denied about AAAA query for
   *.wikipedia.org, on the other hand, Unbound was allowed.  Of course,
   we observed several web site URLs which both BIND and Unbound were
   denied on AAAA queries.

   Table Table 13 shows recheck result by both BIND and Unbound on all
   error messages of DNS64 during the camp (From March 5th to the end of
   closing of March 8th).  Number of NXDOMAIN to AAAA, whose A record
   exist, was abnormal response that indicated failure of fallback to A
   query on DNS64.  Such abnormal AAAA responses was returned to 69
   queries in Unbound case, 201 AAAA queries in BIND case.

         +-------------------+-----------------------------------+
         |     Error Type    | # of unique authoritative servers |
         +-------------------+-----------------------------------+
         |      Refused      |                 47                |
         | ----------------- |   ------------------------------  |
         |      ServFail     |                 66                |
         | ----------------- |   ------------------------------  |
         |     FormError     |                554                |
         +-------------------+-----------------------------------+

               Table 11: The distributions of error messages






Hazeyama, et al.       Expires September 14, 2012              [Page 25]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   +-----------------+-----------------------+-------------------------+
   |    Error Type   |   # of unique auth.   |    # of unique auth.    |
   |                 |     servers (BIND)    |    servers (Unbound)    |
   +-----------------+-----------------------+-------------------------+
   |     NXDOMAIN    |          449          |            21           |
   |    ---------    |       ---------       |        ---------        |
   |  NOERROR Record |           66          |           506           |
   |       = 0       |                       |                         |
   |    ---------    |       ---------       |        ---------        |
   |  NOERROR Record |           9           |            7            |
   |       > 0       |                       |                         |
   |    ---------    |       ---------       |        ---------        |
   |  Others (ex. no |           11          |            20           |
   |      reply)     |                       |                         |
   +-----------------+-----------------------+-------------------------+

            Table 12: Verification FormError of BIND by Unbound

   +-------------------------------------------------------+-----------+
   |                                                       |   number  |
   +-------------------------------------------------------+-----------+
   |             # of names (A, AAAA, PTR, SRV(            |   70886   |
   |                       ---------                       | --------- |
   |               # of names queried by AAAA              |   45633   |
   |                       ---------                       | --------- |
   |           # of NXDOMAIN by AAAA from Unbound          |    4011   |
   |                       ---------                       | --------- |
   |    # of names which A record exist althogh an auth.   |     69    |
   |     server returned NXDOMAIN by AAAA from Unbound     |           |
   |           # of NXDOMAIN by AAAA from Unbound          |    4011   |
   |                       ---------                       | --------- |
   |            # of NXDOMAIN by AAAA from BIND            |    4234   |
   |                       ---------                       | --------- |
   |    # of names which A record exist althogh an auth.   |    201    |
   |       server returned NXDOMAIN by AAAA from BIND      |           |
   +-------------------------------------------------------+-----------+

               Table 13: Statistics of DNS through the camp


5.  Open Issues

5.1.  Dependency between IPv4 and IPv6 address configuration

   In this 2nd experiment, we observed troubles due to the dependency
   between IPv4 and IPv6 address configuration.  We think, both IPv4 and
   IPv6 address configuration SHOULD work independently in a device or
   an OS.



Hazeyama, et al.       Expires September 14, 2012              [Page 26]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


5.2.  PMTUD, MTU mismatch problems and NAT behavior problems

   Through the 2nd experiment, we recognized that PMTUD, MTU mismatch
   problems may be caused not only from lack of fragment support of
   network devices but also difference among OSes' behaviors on MTU /
   packet size handling.  Although we tested the difference between
   Windows 7 and Mac OS Lion on access to a linux server over PPTP
   through SA46T networks, we did not clarify the reason why Mac OS X
   Lion had MTU mismatch that Windows 7 did not face.  PMTUD, MTU
   mismatch problems SHOULD be evaluated through further evaluation.

   KDE's evaluation results indicates that game applications need
   fragment support by network devices and/or OSes.  KDE's evaluation
   results also implies that transition technologies which do not
   provide hairpinning behavior or and Endpoint Independent Mapping
   behavior through IPv6 backbones may not satisfy requirements from
   consumer game products.

   All members of the 2nd experiment team felt that PMTUD, MTU mismatch
   problems are quite serious, and that IETF working groups SHOULD
   reconsider PMTUD, MTU mismatch problems and SHOULD seek more
   practical solution on the current situation.

5.3.  Workaround for DNS64 problems

   As same as the 1st experiment, we met inappropriate DNS authoritative
   servers' behaviors on AAAA queries.  Although the fundamental
   solution is requesting a correction to the administrator who manages
   such 'broken' authoritative server.  Actually, Several DNS servers,
   which returned inappropriate AAAA replies on the 1st experiment, were
   fixed appropriately.  The other work-around solutions that change the
   algorithm of DNS64 can be considered.

5.3.1.  Workaround for illegal NameError

   Even when the result of a query of AAAA record is RCODE 3, ask A
   record, and transform the result of A record to the AAAA record.
   Then, the AAAA record which is converted from A record is cached.
   This workaround makes additional queries when client sends a query
   for the name which has *no* records.  Nevertheless, these results are
   cached, hence DNS64 server does not make extend queries too much.

5.3.2.  Workdaround for lame delegation

   When an authority server is not found (no servers specified as an
   authoritative server, or server doesn't return responses with AA
   bit), A record is asked without returning ServFail and the result of
   A record is transformed.  The AAAA record which is converted from A



Hazeyama, et al.       Expires September 14, 2012              [Page 27]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   record is cached same as section Section 5.3.1.  Assuming If there is
   no authorized A record reply.  DNS64 server sends ServFail to the
   client, and does not cache these records.  Workaround B makes
   additional queries when client sends a query to the zone which has
   lame delegation.


6.  Conclusion and Future Work

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

   This experiment was the second trial on availability test of the IPv6
   only connectivity with participants by WIDE Project.  Many
   participants replied good impressions, however, various issues were
   more clarified through this experiment.

   Through these two experiments, we aware that trouble shooting is very
   hard where multiple protocols are running.  Experiment team prepared
   several testing tools, however, they were not enough to discover of
   causes of troubles.  A standard method of trouble shooting in such
   network condition, criteria, and a touchstone program are needed.  We
   continue to look out for the problematic cases and discuss among
   internet community for the best practice.


7.  Security Considerations

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


8.  IANA Considerations

   This document has no IANA implications.


9.  References





Hazeyama, et al.       Expires September 14, 2012              [Page 28]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


9.1.  Normative References

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

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

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

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

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

9.2.  Informative References

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

   [I-D.draft-ietf-v6ops-464xlat]
              Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation", March
              2012, <draft-ietf-v6ops-464xlat-01 (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]



Hazeyama, et al.       Expires September 14, 2012              [Page 29]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


              Matsuhira, N., "SA46T Multicast Support", September 2011,
              <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", January 2012,
              <draft-matsuhira-sa46t-spec-04 (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.

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

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

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

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC4943]  Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
              Discovery On-Link Assumption Considered Harmful",
              RFC 4943, September 2007.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.




Hazeyama, et al.       Expires September 14, 2012              [Page 30]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC5780]  MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
              Using Session Traversal Utilities for NAT (STUN)",
              RFC 5780, May 2010.

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

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

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

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

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

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

   [SEIL]     Internet Initiative Japan, "SEIL", September 2011,
              <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>.


Appendix A.  Acknowledgments

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

   N. Matsuhira of Fujitsu for SA46T.




Hazeyama, et al.       Expires September 14, 2012              [Page 31]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   R. Nakamura of Keio Univ. for SA46T.

   H. Suenaga and K. Ooyatsu of IIJ for SEIL 4RD.

   JPIX and M. Kawashima of NEC AccessTechnica for 464XLAT.

   NTT-AT guys for providing BIG-IP and Pivot3, which does load
   balancing, DNS64, NAT64, and capturing all traffic.

   Y. Ueno of Keio Univ. for IPv6 L2TP implementation.

   R. Sato and M. Sato of Konami Digital Entertainment Co, Ltd. for NAT/
   Firewall traversal testing.

   NTT EAST, Internet Multifeed, and IIJ for the commercial IPv6
   service.


Authors' Addresses

   Hiroaki Hazeyama
   NAIST
   Takayama 8916-5
   Nara,
   Japan

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


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

   Email: hiromi@inetcore.com


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

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





Hazeyama, et al.       Expires September 14, 2012              [Page 32]


Internet-Draft      IPv6 Experiments in the WIDE Camp         March 2012


   Osamu Nakamura
   WIDE Project
   5322 Endo
   Kanagawa,
   Japan

   Email: osamu@wide.ad.jp












































Hazeyama, et al.       Expires September 14, 2012              [Page 33]


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