Internet DRAFT - draft-hazeyama-widecamp-ipv6-only-experience
draft-hazeyama-widecamp-ipv6-only-experience
Network Working Group H. Hazeyama
Internet-Draft NAIST
Intended status: Informational R. Hiromi
Expires: April 6, 2013 Intec Inc.
T. Ishihara
Univ. of Tokyo
O. Nakamura
WIDE Project
October 3, 2012
Experiences from IPv6-Only Networks with Transition Technologies in the
WIDE Camp Autumn 2012
draft-hazeyama-widecamp-ipv6-only-experience-02
Abstract
This document reports and discusses issues on IPv6 only networks and
IPv4/IPv6 transition technologies through our experiences on the 3rd
experiment on the WIDE camp. The 3rd experiment was held from
September 3rd to September 6th, 2012. As well as past two
experiments, we conducted face to face interview to participants for
grasping IPv6 capability on users' devices, OSes, and applications.
In addition to this, we explored solutions to mitigate timeout /
fallback problems of IPv4/IPv6 dual stack clients on an IPv6 only
network that is composed of DHCP6 and DNS64/NAT64.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hazeyama, et al. Expires April 6, 2013 [Page 1]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hazeyama, et al. Expires April 6, 2013 [Page 2]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. History of ``Live with IPv6 experiments'' on the WIDE
camp . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Summary of the 1st experiment . . . . . . . . . . . . 4
1.1.2. Summary of the 2nd experiment . . . . . . . . . . . . 4
1.2. Abstract of the 3rd experiment . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. Technology and Terminology . . . . . . . . . . . . . . . . . . 7
3. Basic configuration of Network and Experiments . . . . . . . . 8
4. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. An Experiment in RA method . . . . . . . . . . . . . . . . 11
4.1.1. Details of Network Configuration . . . . . . . . . . . 11
4.1.2. User Survey . . . . . . . . . . . . . . . . . . . . . 12
4.1.2.1. Client Profile . . . . . . . . . . . . . . . . . . 12
4.1.2.2. Behaviors of DHCP6 Clients . . . . . . . . . . . . 13
4.1.2.3. Timeout / Fallback Problems . . . . . . . . . . . 14
4.2. Experiments in DHCP-PD method . . . . . . . . . . . . . . 14
4.2.1. Basic Network Configuration . . . . . . . . . . . . . 14
4.2.2. Experiment 0 . . . . . . . . . . . . . . . . . . . . . 15
4.2.2.1. Waiting timeout of DHCP4 in Windows 7 . . . . . . 16
4.2.2.2. Long TCP fallback in Mac OS X Lion and
Mountain Lion . . . . . . . . . . . . . . . . . . 16
4.2.2.3. Incompletion of network settings in iOS 5 . . . . 16
4.2.2.4. Incapability of IPv6 DNS settings by DHCP6 . . . . 16
4.2.3. Experiment 1 . . . . . . . . . . . . . . . . . . . . . 17
4.2.3.1. Diff of network settings . . . . . . . . . . . . . 17
4.2.3.2. Result . . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Experiment 2 . . . . . . . . . . . . . . . . . . . . . 19
4.2.4.1. Diff of network settings . . . . . . . . . . . . . 19
4.2.4.2. Result . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5. Experiment 3 . . . . . . . . . . . . . . . . . . . . . 21
4.2.5.1. Diff of network settings . . . . . . . . . . . . . 21
4.2.5.2. Result . . . . . . . . . . . . . . . . . . . . . . 22
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Hazeyama, et al. Expires April 6, 2013 [Page 3]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
1. Introduction
This document reports and discusses issues on IPv6 only networks and
IPv4/IPv6 transition technologies through our experiences on the 3rd
experiment on the WIDE camp. The 3rd experiment was held from
September 3rd to September 6th in Matsushiro Royal Hotel, Nagano,
Japan, where is the same hotel of the 1st and 2nd experiments.
1.1. History of ``Live with IPv6 experiments'' on the WIDE camp
"Live with IPv6 experiment" aims to evaluate commercial IPv6 network
services, the availability of IPv6 networks with several IPv4 / IPv6
translation / encapsulation technologies by actual users'
experiences, and to grasp issues on IPv4 exhaustion situation or IPv4
/ IPv6 transition. These experiments are based on an assumption that
ISP backbone networks will be constructed on IPv6 only and end
customer will have to use an IPv6 network with 64 translators or an
IPv4 network with 464 translators to keep current usage of the
Internet services.
1.1.1. Summary of the 1st experiment
The 1st experiment was held in Matsushiro Royal Hotel from September
6th to September 9th, 2011 with 153 participants, and the experiment
result was reported in the v6ops BoF on IETF 82 Taipei. In the 1st
experiment, we constructed an IPv6 only network with stateless NAT64
and DNS64 as a part of the WIDE backbone through IPv6 L2TP over a
commercial IPv6 network service. The commercial IPv6 network service
was provided by NTT-East as an Access Carrier, Internet MultiFeed
(MFeed) as a Virtual Network Enabler (VNE) and IIJ as an IPv6
Internet Service Provider (IPv6 ISP). In addition to an IPv6
connectivity with NAT64/DNS64, we also tested a SA46T
[I-D.draft-matsuhira-sa46t-spec] based IPv4 global network service
and a murakami-4RD [I-D.draft-murakami-softwire-4rd] based IPv4
private network service (murakami-4RD is now merged into MAP
[I-D.draft-ietf-softwire-map-02]). With referring IETF's IPv6 only
network experiences [RFC6586], we reported several new issues on an
IPv6 only network with IPv4 / IPv6 transition technologies,
especially on inappropriate DNS replies mentioned in [RFC4074], on
MTU mismatch, on VPN protocols and applications through IPv4 / IPv6
translators.
1.1.2. Summary of the 2nd experiment
According to the experiences on the 1st experiment, the 2nd
experiment was conducted from March 5th to March 8th, 2012 in
Matsushiro Royal Hotel, the same hotel of the 1st experiment. 171
participants joined this 2nd experiment, most of them were engineers
Hazeyama, et al. Expires April 6, 2013 [Page 4]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
or academic people. The 2nd experiment result was reported in the
v6ops BoF on IETF 83 Paris.
The settings of the core network in the 2nd experiment was same as
the 1st experiment. In the 1st experiment, a commercial IPv6 network
service was employed as a backbone network, in other word, we did
evaluate the availability of commercial IPv6 network services from
the view of home users. Therefore, the evaluation target of the 2nd
experiment was planned as living in commercial IPv6 networks with
IPv4 / IPv6 translation technologies or IPv4 / IPv6 translation
services.
The user access networks of the 2nd experiment were achieved by two
types of commercial IPv6 network services through the NTT NGNv6
access network, with four kinds of IPv4 / IPv6 translation
technologies. One of the two commercial IPv6 network services was
/48 prefix IPv6 network service through IPoE[RFC0894] on NTT NGNv6
(we name it "native IPoE" in this draft), the other was /56 prefix
IPv6 network service through PPPoE[RFC2516] on NTT NGNv6 (we label it
"native PPPoE" in this draft) [YasudaAPRICOT2011]. Both IPv6
networks were served from NTT-East, MFeed and IIJ as same as the 1st
experiment.
Usually, IPv6 networks on both native IPoE and native PPPoE were
provided with only DNS v6 proxy. We constructed DNS64/NAT64 service
on the WIDE backbone and on the camp core network, and served it
through stateless DHCP6 [RFC3736] both on native IPoE and on native
PPPoE.
Along with the DNS64/NAT64 translation service, for aiming to
evaluate more practical approaches on the current commercial
environments, we tested three IPv4 services over IPv6 networks,
murakami-4RD [I-D.draft-murakami-softwire-4rd], SA46T
[I-D.draft-matsuhira-sa46t-spec] and 464XLAT
[I-D.draft-ietf-v6ops-464xlat]. We mainly served seven IP networks
to participants by combination of those networks and translation
services, that is, native IPoE with DNS64/NAT64, native PPPoE with
DNS64/NAT64, murakami-4RD on both IPoE and PPPoE, 464XLAT on both
IPoE and PPPoE, SA46T on PPPoE.
Three evaluations were mainly conducted by the evaluation team, i)
user survey about the availability of each network through face to
face interview, ii) analysis of DNS behaviors to grasp inappropriate
behaviors mentioned in [RFC4074], iii) availability test of VPN
applications to analyze MTU problems For to grasp whether an
unavailability of VPN applications was intentional one due to the
specification of a translation technology or not. Also, Konami
Digital Entertainment (KDE) joined in this experiment, and evaluated
Hazeyama, et al. Expires April 6, 2013 [Page 5]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
NAT/Firewall traversal testing on each IPv6 network or each
translator service from the view of commercial (P2P) Network Game
services. KDE gave us the importance / requirements of hair-pinning
functions and of MTU / packet fragmentation handling on NAT/NAPT for
P2P based Multiplayer Online Games.
1.2. Abstract of the 3rd experiment
The 3rd experiment was conducted from September 3rd to September 6th,
2012 in Matsushiro Royal Hotel, the same hotel of the past two
experiments. 136 participants joined this 3rd experiment, most of
them were engineers or academic people.
The aims of 3rd experiments were 1) continuous user survey on IPv6
capability of devices, OSes and applications, 2) exploration of a
practical solution to mitigate timeout / fallback problems of IPv4/
IPv6 dual stack clients on an IPv6 only network.
The first aim was conducted to grasp the IPv6 capability of users'
devices, OSes, and applications and to collect users' experiences
through face to face interview. From the 2nd experiments, several
new OSes or new devices have been released. Through this continuous
survey, we saw the current development / deployment strategy of IPv6
on commercial vendors or Telecom / Internet Service providers. This
user survey was mainly carried on September 3rd and September 4th.
The second aim was derived from our experiences of an IPv6 only
network with DHCP6/DNS64/NAT64 on past two experiments. In past two
experiments, various OSes met several timeout / fallback problems, in
the initial connection setting through Wi-Fi settings, in the name
server selection, in the establishment of a TCP connection. Most
OSes and applications, that met tedious timeout / fallback problems,
preferred IPv4 to IPv6, or required IPv4 settings to enable IPv6
settings. These timeout / fallback problems were seemed to be
derived from an assumption that there are no IPv6 only network on the
current situation.
Toward the sunset of IPv4, we have to explore and achieve a practical
solution to move from IPv4/IPv6 dual stack networks to IPv6 only
networks without giving stress or difficulties to end users. In
IPv4/IPv6 transition situation, end users will usually use IPv4/IPv6
dual stack mode, and they will leave all IPv4 / IPv6 network settings
by OSes' auto configuration behaviors on their devices except for
selecting Wi-Fi connections.
We focused on testing an IPv6 only network that was basically
composed of DHCP6, DNS64 and NAT64. In this IPv6 only network, we
sought a current practice of timeout / fallback mitigation among
Hazeyama, et al. Expires April 6, 2013 [Page 6]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
IPv4/IPv6 dual stack networks and IPv6 only networks. According to
results of the user survey, we added several functions to a basic
DHCP6/DNS64/NAT64 network in step by step fashion, and we analyzed or
revised mitigation methods for timeout / fallback problems.
This draft is composed of following sections. We explain the
overview of the network settings in the 3rd experiment at first.
Next, we report the result of the user survey. Then, we describe the
experiment on timeout / fallback mitigation methods. Finally, we
summarize our practical timeout / fallback mitigation method. We
also mention about limitations our mitigation method and our
recommendations on development / deployment of IPv6 capability on end
clients.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Technology and Terminology
In this document, the following terms are used. "NAT44" refers to
any IPv4-to-IPv4 network address translation algorithm, both "Basic
NAT" and "Network Address/Port Translator (NAPT)", as defined by
[RFC2663].
"Dual Stack" refers to a technique for providing complete support for
both Internet protocols -- IPv4 and IPv6 -- in hosts and routers
[RFC4213].
"NAT64" refers to a Network Address Translator - Protocol Translator
defined in [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6384].
"DNS64" refers DNS extensions to use NAT64 translation from IPv6
clients to IPv4 servers with name resolution mechanisms that is
defined in [RFC6147].
"DHCP4" refers Dynamic Host Configuration Protocol for IPv4 that is
defined in [RFC2131].
"DHCP6" refers Dynamic Host Configuration Protocol for IPv6. So
called "Stateful DHCP6" is defined in [RFC3315] and "Stateless DHCP6"
is defined in [RFC3736]. "DHCP-PD" or "DHCPv6 Prefix Delegation"
refers IPv6 Prefix Options for DHCP6 that is initially defined in
[RFC3633] and updated in [RFC6603].
Hazeyama, et al. Expires April 6, 2013 [Page 7]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
"ND" refers Neighbor Discovery for IP version 6 (IPv6) that is
defined in [RFC4861] and updated in [RFC5942].
3. Basic configuration of Network and Experiments
The WIDE Camp Autumn 2012 was held at Matsushiro Royal Hotel in
Nagano Prefecture of Japan, the same place of the 1st and 2nd
experiment, from September 3rd to September 6th, 2012. Figure 1
shows the overview of the whole network topology on the WIDE Camp
Autumn 2012.
Besides our IPv6 only experiments, the camp NOC team set up a core
network (camp-net-core) for preparing a backup plan of our IPv6 only
network experiments and for conducting other experiments such as OLSR
emulation, SA46T-AT [I-D.draft-matsuhira-sa46t-at-00] and NAT44
double translation, and measurement of a satellite link. All server
instances and routing instances of the core network were built on
StarBED that is a cloud / network emulation testbed in Japan. We
constructed two layer 2 tunnels between StarBED and Matsushiro Royal
hotel through IPv4 PPPoE. The layer 2 tunnels over IPv4 PPPoE were
constructed by NEC IX2015. The OLSR network and the satellite link
were served as IPv4 / IPv6 dual stack networks. The wireless
Accesses to these networks were provided by CISCO Systems Mesh Wi-Fi
Access Point and WLC (Wireless LAN Controller).
As well as our 2nd experiment, a commercial IPv6 service was employed
to achieve our IPv6 only network experiments. The Access Carrier
(AC), the Virtual Network Enabler (VNE) and the IPv6 Internet Service
Provider (v6ISP) of this 3rd experiment were same combination of past
experiments, that is, NTT-East as AC, MFeed as the VNE and IIJ Mio as
v6ISP. We contracted two external FTTH lines by NTT NGNv6 IPoE
method. We changed the IPv6 address allocation method on NTT NGNv6
IPoE during this camp.
From September 2th (the preparation day) to September 4th, we used
the RA method for the external connectivity. Figure 2 represents
details of the IPv6 only network by RA method. From September 5th to
September 6th, we changed the external connectivity to the DHCP-PD
method.
In the RA method, we tested the DHCP6 client behaviors when two
stateless DHCP6 servers exist, one is placed by the VNE or ISP to
indicate AAAA name servers, the other is located in the local subnet
to lead clients to a DNS64 name server. On the other hand, we
explored mitigation methods for timeout / fallback problems after we
changed the external connectivity to the DHCP-PD method. We explain
the experiment on the RA method in Section 4.1 and the experiments on
Hazeyama, et al. Expires April 6, 2013 [Page 8]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
the DHCP-PD method in Section 4.2, respectively.
We employed following implementations for key components;
o DNS64 and recursive cache server: NLNet Labs Unbound 1.4.7 with
DNS64 patch
o NAT64 : OpenBSD 5.1 PF (Packet Filter)
o DHCP-PD client : WIDE DHCP client (dhcp6c)
o Stateless DHCP6 server : Alaxala 3630
Hazeyama, et al. Expires April 6, 2013 [Page 9]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
+----------------------------------------------------+
| The Internet (IPv4 / IPv6) |
+----------------------------------------------------+
| | |
| | |
+-----------+ | +--------------+
| IIJ (ISP) | | | WIDE (ISP) |---------+
+-----------+ | +--------------+ |
| | | | |
| | | (L2 Tunnel) |
| | (IPv4/IPv6) | |
| | | +---------+ |
| | | | IX 2015 | |
+-----------+ | +---------+ |
|MFeed (VNE)| | | |
+-----------+ +---------------+ +-------------+
| | camp-net-core | | SAT station |
| +---------------+ +-------------+
| |
+--------------------------+ |
| NTT NGNv6 (Access Line) | (satellite link)
+--------------------------+ |
| | +-------------+
(IPoE method) | SAT station |
| | +-------------+
| +--------------+ |
| | | |
(native IPv6) (L2 tunnel over IPv4 PPPoE) (L2 Tunnel)
| | | |
| | +---------+ +---------+
| | | IX 2015 | | IX 2015 |
| | +---------+ +---------+
| | | |
| | (vlan) (vlan)
| | | |
+------------------------------------------------------------+
| Wi-fi Access (CISCO Layer 2 mesh, 11b/g/n Wi-fi) |
+------------------------------------------------------------+
Over view of the 2nd experiment topology
Figure 1
Hazeyama, et al. Expires April 6, 2013 [Page 10]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
4. Experiments
4.1. An Experiment in RA method
4.1.1. Details of Network Configuration
The experiment conducted in RA method was overwriting client DNS
information by a local stateless DHCP6 server. Figure 2 shows the
test network topology. The RA method provided /64 prefix addresses
and routing information through RA. The RA was set managed flag as
zero (M flag == 0) and the other flag to one (O flag == 1) to let
clients query to stateless DHCP6 servers. In this case, a stateless
DHCP6 server was placed on the VNE network of MFeed and IIJ that
advertised two AAAA name servers. Those two AAAA name servers
returned only AAAA records to any queries.
We wanted to inform only the DNS64 IPv6 address to clients on this RA
method while using address assignment and default route settings by
the RA method. Of course, we could not control the DHCP6 server on
the VNE network. Therefore, we tried to use the preference option of
DHCP6.
The preference option of DHCP6 (section 22.8 of [RFC3315]) defines
that "the Preference option is sent by a server to a client to affect
the selection of a server by the client". Section 17.1.3 of
[RFC3315] defines the criteria on the behavior of DHCP6 server
selection by a client when the client has received two or more valid
advertise messages;
o Those Advertise messages with the highest server preference value
are preferred over all other Advertise messages.
o Within a group of Advertise messages with the same server
preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to the
client. For example, the client may choose a server that returned
an advertisement with configuration options of interest to the
client.
o The client MAY choose a less-preferred server if that server has a
better set of advertised parameters, such as the available
addresses advertised in IAs.
We assumed we could overwrite the name server information by sending
advertise messages with highest preference value from a local
stateless DHCP6 server. Thus, we placed a local stateless DHCP6
server shown in Figure 2.
Hazeyama, et al. Expires April 6, 2013 [Page 11]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
This overwriting was partially succeeded as well as we assumed,
however, several inconveniences were reported through face to face
interview and inspection by the special observation team.
+-------+ +------+
| DNS64 | | NAT64|
+-------+ +------+
| |
(-- StarBED --)
| |
+--------------- IPv6 Internet ----------------------+
|
+-------------+
| IPv6 router |
| on ISP |
+-------------+
|
+---------+ +---------+ +----------+ +---------+
| IPv6 GW | | DHCP6 | |AAAA name | | DHCP6 |
| | | to AAAA | | servers | | to DNS64|
+---------+ +---------+ +----------+ +---------+
| | | |
(---------- VNE --------------) (-- Hotel --)
| | | |
+---------------- /64 prefix segment -----------------------+
|
+---------------+
| users devices |
+---------------+
The Test Topology on RA method
Figure 2
4.1.2. User Survey
59 participants (42.8 %) replied our face to face interview. We show
the client profile in Section 4.1.2.1 and reported troubles in
Section 4.1.2.2 and Section 4.1.2.3.
4.1.2.1. Client Profile
94 unique devices were profiled. The distribution of the pair of
device and OS were shown in Table 1.
Hazeyama, et al. Expires April 6, 2013 [Page 12]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
+-------------------+----------------------+-------------------+
| Device Type | OS Type | # of devices (%) |
+-------------------+----------------------+-------------------+
| PC/AT Note PC | Windows 7 | 16 (17.0 %) |
| ----------------- | ----------------- | ----------------- |
| PC/AT Note PC | NetBSD | 2 (2.1 %) |
| ----------------- | ----------------- | ----------------- |
| PC/AT Note PC | Linux | 4 (4.3 %) |
| ----------------- | ----------------- | ----------------- |
| Apple Note PC | Mountain Lion | 15 (16.0 %) |
| ----------------- | ----------------- | ----------------- |
| Apple Note PC | Lion | 18 (19.1%) |
| ----------------- | ----------------- | ----------------- |
| Apple Note PC | Snow Leopard | 9 (9.6 %) |
| ----------------- | ----------------- | ----------------- |
| Apple Note PC | Windows 7 (Bootcamp) | 3 (3.2 %) |
| ----------------- | ----------------- | ----------------- |
| iPhone / iPod | iOS 5 | 9 (9.6 %) |
| ----------------- | ----------------- | ----------------- |
| Android Phone | Android OS 4 | 3 (3.2 %) |
| ----------------- | ----------------- | ----------------- |
| Android Phone | Android OS 2 | 4 (4.3 %) |
| ----------------- | ----------------- | ----------------- |
| Android Phone | Android OS 1 | 1 (1.0 %) |
| ----------------- | ----------------- | ----------------- |
| iPad | iOS 6 | 1 (1.0 %) |
| ----------------- | ----------------- | ----------------- |
| iPad | iOS 5 | 6 (6.4 %) |
| ----------------- | ----------------- | ----------------- |
| Android Tablet | Android OS 4 | 2 (2.1 %) |
| ----------------- | ----------------- | ----------------- |
| Kindle | Kindle 3.3 | 1 (1.0 %) |
| ----------------- | ----------------- | ----------------- |
| Total | | 94 |
+-------------------+----------------------+-------------------+
Table 1: The distributions of devices of participants
4.1.2.2. Behaviors of DHCP6 Clients
Many users reported inconveniences of DHCP6 client behaviors in the
RA method. We focused on the analysis of DHCP6 client behavior of
Windows 7 and of Mac OS X Lion / Mountain Lion. Both Windows 7 and
Mac OS X usually stored DNS64 IPv6 address to their name server
information, however, both of them sometime stored two AAAA name
servers on the VNE network. Differences of their DHCP6 client
behaviors were as follows;
Hazeyama, et al. Expires April 6, 2013 [Page 13]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
o In most cases, Windows 7 preferred to the advertise message from
the local DHCP6 server that indicated the DNS64 server, however,
it often preferred the advertise message from the DHCP6 server on
the VNE network at the RA refresh timing.
* When the DHCP6 client preferred to the DHCP6 server on the VNE
network, an user had to reset the Wi-Fi device of his/her PC
and to reconnect to the Wi-Fi network. "ipconfig /renew" or
simply reconnecting by Wi-Fi selection icon often failed to
prefer the advertise message from the local DHCP6 server.
o On the other hand, Mac OS X Lion and Mountain Lion often failed to
prefer the advertise message from the local DHCP6 server at the
initial set up on Wi-Fi setting, however, "Renew DHCP lease" on
the detail of network settings always preferred to the advertise
message from the local DHCP6 server, that is, Mac OS X always
changed the name server setting to only DNS64 IPv6 address by
"Renew DHCP lease". At RA refresh timing, Mac OS X sometime
preferred to the DHCP6 server on the VNE network, then, the user
had to refresh DHCP configurations again.
4.1.2.3. Timeout / Fallback Problems
Many users reported inconveniences due to timeout / fallback
problems. Root causes were roughly categorized into 1) troubles of
DNS64, 2) incapability of IPv6 and of DNS64 on various servers and
applications mentioned in [RFC4074] and [RFC6586], 3) incapability of
DHCP6 client and / or IPv4 dependency on OSes. In Section 4.2, we
explain the detail of timeout / fallback problems without effects by
the selection of stateless DHCP6 servers.
4.2. Experiments in DHCP-PD method
On the contrary of the RA method mentioned in Section 4.1, the
DHCP-PD method provided /56 prefix delegation by DHCP6 prefix
delegation mechanism. We settled a DHCP-PD client PC router and set
up static routes to two delegated /64 networks, one was labeled as
"v6only-basic", the other was named as "v6only-fallback". The
v6only-basic network was a basic IPv6 only network that was composed
of stateless DHCP6, DNS64 and NAT64. On the other hand, we tested
several timeout / fallback mitigation methods in "v6only-fallback".
Figure 3 shows the basic network topology of experiments on DHCP-PD
method.
4.2.1. Basic Network Configuration
Figure 3 shows the basic network topology of experiments on DHCP-PD
method.
Hazeyama, et al. Expires April 6, 2013 [Page 14]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
+-------+ +------+
| DNS64 | | NAT64|
+-------+ +------+
| |
(-- StarBED --)
| |
+--------------- IPv6 Internet ----------------------+
|
+-------------+ +----------------+
| IPv6 router | | DHCP PD server |
| on ISP | | on VNE |
+-------------+ +----------------+
| |
+-- (VNE network) ----------------+----------------------+
|
|(v6)
|
(---- Hotel ----)
|
+---------------+
| DHCP-PD Client|
| PC router |
+---------------+
|
+-----------------+ |
| Stateless DHCP6 | |
+-----------------+ |
| |
| |
+------------- each /64 prefix segment ---------------+
|
+---------------+
| users devices |
+---------------+
Basic Network Topology on DHCP-PD method (v6only-basic)
Figure 3
4.2.2. Experiment 0
In the experiment 0, we observed OSes behaviors again. Actually, the
inconvenience on the selection of two stateless DHCP6 servers were
resolved by DHCP-PD and placing one stateless DHCP6 server onto each
/64 prefix subnet. However, we clearly recognized several timeout /
fallback problems. In following sections, we explain timeout /
fallback problems due to DHCP6 client incapability and IPv4
Hazeyama, et al. Expires April 6, 2013 [Page 15]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
dependency of OSes.
4.2.2.1. Waiting timeout of DHCP4 in Windows 7
In Windows 7, timeout of DHCP4 queries spent a few minutes in the
initial Wi-Fi connection setup. After fallback on the initial Wi-Fi
connection, there were no problem on using IPv6 capable applications.
DNS64 fallback failures due to the inappropriate authoritative
servers still occurred, however, several authoritative servers, that
returned inappropriate AAAA reply in past experiments, had been fixed
to have appropriate fallback.
4.2.2.2. Long TCP fallback in Mac OS X Lion and Mountain Lion
Mac OS X implementations, such as Lion and Mountain Lion, had more
serious timeout / fallback problems than Windows 7. After the
timeout of DHCP4 queries with a few minutes as well as Windows 7, the
interface that is allocated IPv4 link local address was inserted as
IPv4 default route. This Mac OS X behavior may be along with IPv4
on-link assumption in Section 3.3 of [RFC3927]. Section 3.3 of
RFC3927 mentions "Interaction with Hosts with Routable Addresses",
which assumes all IPv4 address are on-link at Link-Local
configuration.
Also, getaddrinfo implementation on Mac OS X did HappyEyeball like
behavior. The getaddrinfo of Mac OS X returned an IP address list
where IPv4 addresses were inserted the top of the list initially.
Combining the on-link-assumption and the HappyEyeball like
getaddrinfo caused long long TCP fallback from IPv4 to IPv6 in the
initial TCP connection setup. Once the long long TCP fallback
occurred, getaddrinfo of Mac OS X marked some flag that IPv4 is not
available at the moment, then the getaddrinfo gave higher priority to
IPv6 addresses than IPv4 addresses until ARP and / or ND tables were
refreshed. When ARP and / or ND tables were refreshed, Mac OS X
users face long long TCP fallback from IPv4 to IPv6 again.
4.2.2.3. Incompletion of network settings in iOS 5
In iOS 5, "Network Setting" were not completed, "Network Settings"
will be completed only if IPv4 address, IPv4 router, and IPv4 DNS can
be retrieved via DHCPv4 or manually configured all of these 3.
4.2.2.4. Incapability of IPv6 DNS settings by DHCP6
Windows XP, older Mac OS X (Snow Leopard and older) and Android OS
required an IPv4 address for an DNS server even when they can use
IPv6. In an IPv6 only network, DNS information should be gotten via
DHCP6, these OSes did not support DHCP6 client. Also, Android cannot
Hazeyama, et al. Expires April 6, 2013 [Page 16]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
be configured to use DNS over IPv6 even in manual configuration.
4.2.3. Experiment 1
4.2.3.1. Diff of network settings
In the Experiment 1, we added a DHCP4 server that provided only IPv4
private address to DHCP4 client without the default gateway IPv4
address nor IPv4 address of DNS. We employed ISC-DHCP for this DHCP4
server.
Hazeyama, et al. Expires April 6, 2013 [Page 17]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
+-------+ +------+
| DNS64 | | NAT64|
+-------+ +------+
| |
(-- StarBED --)
| |
+--------------- IPv6 Internet ----------------------+
|
+-------------+ +----------------+
| IPv6 router | | DHCP PD server |
| on ISP | | on VNE |
+-------------+ +----------------+
| |
+-- (VNE network) ----------------+----------------------+
|
|(v6)
|
(---- Hotel ----)
|
+---------------+
| DHCP-PD Client|
| PC router / |
| DHCP4 |
+---------------+
|
+-----------------+ |
| Stateless DHCP6 | |
+-----------------+ |
| |
| |
+------------- /64 prefix segment ---------------+
|
+---------------+
| users devices |
+---------------+
Test Topology on Experiment 1 (v6only-fallback)
Figure 4
4.2.3.2. Result
As the result of Experiment 1, only timeout of DHCP4 was solved, that
is, only Windows 7 was working well without any fallback problems
except for DNS64 name resolving. TCP fallback problem on MacOS X
still occurred. iOS applications were sometimes working, but
periodically failed due to retrying Wi-Fi connection setup.
Hazeyama, et al. Expires April 6, 2013 [Page 18]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
4.2.4. Experiment 2
4.2.4.1. Diff of network settings
In the Experiment 2, we put BIND9 forwarder on-link and configured
DHCP4/6 to use this DNS. We configured BIND9 forwarder with: * deny-
answer-addresses { 0.0.0.0/0; }; * which directed that no IPv4
address answer should be trusted. It returned SERVFAIL to resolvers.
Hazeyama, et al. Expires April 6, 2013 [Page 19]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
+-------+ +------+
| DNS64 | | NAT64|
+-------+ +------+
| |
(-- StarBED --)
| |
+--------------- IPv6 Internet ----------------------+
|
+-------------+ +----------------+
| IPv6 router | | DHCP PD server |
| on ISP | | on VNE |
+-------------+ +----------------+
| |
+-- (VNE network) ----------------+----------------------+
|
|(v6)
|
(---- Hotel ----)
|
+------------------+
| DHCP-PD Client |
| PC router / |
| DHCP4 / |
| Bind 9 forwarder |
| which treats "A" |
| as SERVAFAIL |
+------------------+
|
+-----------------+ |
| Stateless DHCP6 | |
+-----------------+ |
| |
| |
+------------- /64 prefix segment ---------------+
|
+---------------+
| users devices |
+---------------+
Test Topology on Experiment 2 (v6only-fallback)
Figure 5
Hazeyama, et al. Expires April 6, 2013 [Page 20]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
4.2.4.2. Result
As result of Experiment 2, Android was working well. iOS was working,
but periodically failed due to retrying to Wi-Fi connection setup.
MacOS X variants were working, but timeout by TCP fallback still
occurred. Windows XP was not working because all DNS queries failed
due to SERVFAIL.
4.2.5. Experiment 3
4.2.5.1. Diff of network settings
In the Experiment 3, we hacked AAAA filtering code on BIND9 to filter
"A records" instead of "AAAA records" both on IPv4/IPv6 transport.
We put BIND9 above to the local link, which was configured to forward
all queries to DNS64. We also configured DHCP4/DHCP6 to use the DNS
proxy.
Hazeyama, et al. Expires April 6, 2013 [Page 21]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
+-------+ +------+
| DNS64 | | NAT64|
+-------+ +------+
| |
(-- StarBED --)
| |
+--------------- IPv6 Internet ----------------------+
|
+-------------+ +----------------+
| IPv6 router | | DHCP PD server |
| on ISP | | on VNE |
+-------------+ +----------------+
| |
+-- (VNE network) ----------------+----------------------+
|
|(v6)
|
(---- Hotel ----)
|
+-------------------+
| DHCP-PD Client |
| PC router / |
| DHCP4 / |
| Bind 9 DNS Proxy |
| with "A" filter |
+-------------------+
|
+-----------------+ |
| Stateless DHCP6 | |
+-----------------+ |
| |
| |
+------------- /64 prefix segment ---------------+
|
+---------------+
| users devices |
+---------------+
Test Topology on Experiment 3 (v6only-fallback)
Figure 6
4.2.5.2. Result
As the result of Experiment 3, Windows XP, MacOS X variants, iOS,
Android were working well. Some of applications still failed on IPv6
only due to the IPv6 incapability or DNS64 fallback problem, but many
Hazeyama, et al. Expires April 6, 2013 [Page 22]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
cases were fine: IE/Safari/Chrome/Firefox, Twitter, Facebook,
Instagram, and so on.
Remaining issues were connection failures during a few minutes after
Wi-Fi was connected. We guess the possible reason of this failures
as follows: RS (Router Solicitation) was sent from kernel before
Wi-Fi link was established. No IPv6 address was obtained until
periodical RA (Router Advertisement) was received. The possible
workaround to this connection failure is shortening RA interval to
5-10 seconds (though it disturb Wi-Fi ...) or detecting association
through AP log and kicking RS or RA.
5. Conclusion
Timeout / fallback problems on IPv4/IPv6 dual stack clients in an
IPv6 only network are caused by
1. timeout and fallback sequence on DHCP4 queries,
2. timeout and fallback sequence on the connectivity check to the
IPv4 internet after the DHCP4 auto configuration,
3. connection retry sequence when the connectivity to the IPv4
internet was not given.
4. timeout and fallback sequence of a TCP connection on Mac OS X
variants due to their HappyEyeball like behavior of getaddrinfo,
5. preference / dependency of IPv4 on name resolution,
6. connection failures during 1-2 minutes after Wi-Fi was connected.
To mitigate these timeout / fallback problems, our current practice
is composed of following components;
o Configure a DNS64 and a NAT64 in somewhere.
o Configure a Dual-stack DNS proxy as follows
* The DNS proxy forwards all queries to the DNS64 except "A"
query type (IPv4 address). Since there is no IPv4 connectivity
on the client, all queries to "A" should be filtered and the
DNS proxy returns NO DATA, just like "AAAA" filtering.
* This "A" filter should be enabled both on IPv4 and IPv6
transport.
Hazeyama, et al. Expires April 6, 2013 [Page 23]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
* This Dual-stack "A" filter DNS proxy should be "on-link" and
reachable from IPv4/IPv6 dual stack mode clients.
o Configure a DHCP4 server to reply a private IPv4 address, an IPv4
gateway router, and IPv4 address of an "A" filter DNS proxy to
DHCP4 client.
o Configure a DHCP6 server to indicate the IPv6 address of "A"
filter DNS Proxy to DHCP6 client.
* The IPv6 address of "A" filter DNS Proxy may be provided to
IPv4/IPv6 dual stack mode clients by RDNSS [RFC6106]. However,
from our experience on hot stage of Camp 1209 Autumn, Mac OS X
Lion and Mountain Lion could handle RDNSS, but Windows 7 did
not handle RDNSS.
* Only one DHCP6 server should be placed in each /64 prefix
segment or indicated by DHCP6 relay. According to our
experience, we do not recommend overwriting DNS information by
a local stateless DHCP6 server with highest preference value
due to the differences of handling multiple DHCP6 replies among
DHCP6 client implementations.
o Configure the IPv4 gateway router not to forward any IPv4 packets.
6. Security Considerations
As well as Arkko mentioned in [RFC6586], the use of IPv6 instead of
IPv4 by itself does not make a big security difference. In our
experience, we only set up following security functions; the access
control list on routers / servers, accounting on the wireless network
access.
7. IANA Considerations
This document has no IANA implications.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Hazeyama, et al. Expires April 6, 2013 [Page 24]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
8.2. Informative References
[I-D.draft-ietf-softwire-map-02]
Troan, O., Bao, C., Matsushima, S., and T. Murakami,
"Mapping of Address and Port with Encapsulation (MAP)",
September 5, 2012, <draft-ietf-softwire-map-02 (work in
progress)>.
[I-D.draft-ietf-v6ops-464xlat]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
September 2012, <draft-ietf-v6ops-464xlat-08 (work in
progress)>.
[I-D.draft-matsuhira-sa46t-at-00]
Matsuhira, N., Horiba, K., Ueno, Y., and O. Nakamura,
"SA46T Address Translator", July 2011,
<draft-matsuhira-sa46t-at-00 (work in progress)>.
[I-D.draft-matsuhira-sa46t-spec]
Matsuhira, N., "Stateless Automatic IPv4 over IPv6
Tunneling: Specification", July 2012,
<draft-matsuhira-sa46t-spec-05 (work in progress)>.
[I-D.draft-murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "Stateless
Automatic IPv4 over IPv6 Tunneling: Specification",
September 2011, <draft-murakami-softwire-4rd-01 (work in
progress)>.
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams
over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
Hazeyama, et al. Expires April 6, 2013 [Page 25]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, July 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
Hazeyama, et al. Expires April 6, 2013 [Page 26]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
[YasudaAPRICOT2011]
Yasuda, A., "Building for IPv6 by IPv6 Promotion Council
Japan.", February, 2011, <http://meetings.apnic.net/
__data/assets/pdf_file/0003/30981/
Ayumu-Yasuda-apricot.pdf>.
Appendix A. Acknowledgments
Here, we thank to all the participants of WIDE camp on the
experiments. We also say thank you to whom serving implementations
and services in the Matsushiro Royal Hotel.
R. Nakamura of Univ. of Tokyo, Y. Ueno of Keio Univ. and R. Shouhara
of Univ. of Tokyo for helping us on the base settings of the IPv6
only experiments and merging into the camp-net.
O. Onoe of Sony Corporation for his deep inspection and testing of
end node devices.
T. Jimei of Internet Systems Consortium for his quick hack on A
filter of Bind 9.
Y. Atarashi of Alaxala Networks and R. Atarashi of IIJ Innovation
Institute for designing the items of face to face interview and
analyzing user survey data.
Authors' Addresses
Hiroaki Hazeyama
NAIST
Takayama 8916-5
Nara,
Japan
Phone: +81 743 72 5216
Email: hiroa-ha@is.naist.jp
Hazeyama, et al. Expires April 6, 2013 [Page 27]
Internet-Draft IPv6 Experiments in the WIDE Camp October 2012
Ruri Hiromi
Intec Inc.
1-3-3 Shin-Suna, Koutou
Tokyo,
Japan
Email: hiromi@inetcore.com
Tomohiro Ishihara
Univ. of Tokyo
3-8-1 Komaba, Meguro
Tokyo,
Japan
Email: sho@c.u-tokyo.ac.jp
Osamu Nakamura
WIDE Project
5322 Endo
Kanagawa,
Japan
Email: osamu@wide.ad.jp
Hazeyama, et al. Expires April 6, 2013 [Page 28]
