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]