Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011
draft-hazeyama-widecamp-ipv6-only-experience-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hiroaki Hazeyama , Yukito Ueno | ||
| Last updated | 2011-10-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hazeyama-widecamp-ipv6-only-experience-00
Network Working Group H. Hazeyama
Internet-Draft NAIST
Intended status: Informational Y. Ueno
Expires: April 26, 2012 Keio Univ.
October 24, 2011
Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011
draft-hazeyama-widecamp-ipv6-only-experience-00
Abstract
This document discusses our experiences from the IPv6 only network
experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The
WIDE camp Autumn 2011 was held from September 6th to September 9th,
2011, with 153 participants.This document reports answers of
questionnaire from participants, troubles and causes, with referring
IETF's IPv6 only network experiences.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Hazeyama & Ueno Expires April 26, 2012 [Page 1]
Internet-Draft Abbreviated Title October 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4
3. Network and Experiment Setup . . . . . . . . . . . . . . . . . 5
3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 6
3.1.1. External Links . . . . . . . . . . . . . . . . . . . . 7
3.1.2. IPv6 Tunnel . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. DHCP6 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4. DNS64 and NAT64 . . . . . . . . . . . . . . . . . . . 8
3.2. The IPv4 Networks . . . . . . . . . . . . . . . . . . . . 8
3.2.1. The IPv4 Network through SA46T . . . . . . . . . . . . 8
3.2.2. The IPv4 Network through 4RD . . . . . . . . . . . . . 8
4. Experiences from the Experiments . . . . . . . . . . . . . . . 9
4.1. Answers of Questionnaire . . . . . . . . . . . . . . . . . 9
4.1.1. The distributions of connectivities that
participants used . . . . . . . . . . . . . . . . . . 10
4.1.2. The satisfaction on the IPv6 only connectivity . . . . 10
4.1.3. The satisfaction on the network quality . . . . . . . 11
4.2. Reported Troubles . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Troubles on the IPv6 capability of OSes and Devices . 11
4.2.1.1. Pains due to long fallback routine . . . . . . . . 12
4.2.1.2. Pains due to lack of DHCP6 capability . . . . . . 12
4.2.1.3. Pains due to the OS's incapability on IPv6
only setting . . . . . . . . . . . . . . . . . . . 12
4.2.1.4. Pains due to the device's incapability for IPv6 . 12
4.2.1.5. Failure of settings through GUI . . . . . . . . . 12
4.2.2. Troubles on Applications . . . . . . . . . . . . . . . 12
4.2.2.1. Pains due to IPv6 incapability on applications . . 13
4.2.2.2. Failures due to incapability of protocol
translation between IPv4 and IPv6 . . . . . . . . 13
4.2.2.3. Failures due to MTU mismatch problems . . . . . . 13
4.2.3. Troubles on Name Resolution . . . . . . . . . . . . . 13
4.2.3.1. Failures due to IPv4 address literals . . . . . . 14
4.2.3.2. Failures due to lack of reverse lookup entries
on AAAA records . . . . . . . . . . . . . . . . . 14
4.2.3.3. Failures due to the lame delegation . . . . . . . 14
4.2.3.4. Pains due to the overload of DNS64 . . . . . . . . 14
4.2.3.5. Failures due to inappropriate AAAA replies . . . . 15
5. Lessons from the experiences on the WIDE camp . . . . . . . . 15
6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. PMTUD, MTU mismatch problems . . . . . . . . . . . . . . . 16
6.2. Inappropriate AAAA replies . . . . . . . . . . . . . . . . 16
Hazeyama & Ueno Expires April 26, 2012 [Page 2]
Internet-Draft Abbreviated Title October 2011
7. Conclusion and Future Work . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Hazeyama & Ueno Expires April 26, 2012 [Page 3]
Internet-Draft Abbreviated Title October 2011
1. Introduction
This document discusses our experiences from the IPv6 only network
experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The
WIDE camp Autumn 2011 was held from September 6th to September 9th,
2011, with 153 participants. The main purposes of our experiment in
the WIDE camp were to grasp how much participants could live in the
IPv6 only connectivity environment, and to clarify what kind problems
would occurred on the operation through actual users' experiences of
the IPv6 only connectivity brought by DHCP6 [RFC3736] and the 6to4
translation by DNS64 and NAT64. This document reports answers of
questionnaire from 110 participants (71.9% of the whole
participants), troubles reported to the NOC team and causes that the
NOC team analyzed. Also, we refer to the IETF's IPv6 only network
experiences [I-D.draft-arkko-ipv6-only-experience], we try to clarify
new issues on IPv6 transition operation.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Technology and Terminology
In this document, the following terms are used. "NAT44" refers to
any IPv4-to-IPv4 network address translation algorithm, both "Basic
NAT" and "Network Address/Port Translator (NAPT)", as defined by
[RFC2663].
"Dual Stack" refers to a technique for providing complete support for
both Internet protocols -- IPv4 and IPv6 -- in hosts and routers
[RFC4213].
"NAT64" refers to a Network Address Translator - Protocol Translator
defined in [RFC6052], [I-D.ietf-behave-v6v4-framework],
[I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful],
[I-D.ietf-behave-dns64], [I-D.ietf-behave-ftp64].
"SA46T" refers to Stateless Automatic IPv4 over IPv6 Tunneling
defined in [I-D.draft-matsuhira-sa46t-motivation],
[I-D.draft-matsuhira-sa46t-as], [I-D.draft-matsuhira-sa46t-spec],
[I-D.draft-matsuhira-sa46t-gaddr],
[I-D.draft-matsuhira-sa46t-applicability],
[I-D.draft-matsuhira-sa46t-mcast].
"4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure
Hazeyama & Ueno Expires April 26, 2012 [Page 4]
Internet-Draft Abbreviated Title October 2011
defined in [I-D.draft-murakami-softwire-4rd].
3. Network and Experiment Setup
The WIDE camp autumn 2011 was held at Mastushiro Royal Hotel in
Nagano Prefecture of Japan from September 6th to September 9th, 2011.
We set up the IPv6 only network as the main conference network
connectivity. The conference network connectivity were mainly served
as wireless networks. The served IPv6 only network was not a pure
IPv6 only network because most participants had not IPv6 environment
on his / her organization, yet. Therefore, we served an IPv6
connectivity with 6to4 translation mechanisms, that is, with NAT64
and DNS64.
153 participants joined in the conference and tried the IPv6 only
connectivity through their own devices, such as Laptop PCs, smart
phones, and so on at September 6th and 7th, 2011. Participants
reported their experiences or troubles through questionnaire, emails,
and / or directly claims to the NOC team.
As a last resort for IPv4 only OSes or applications, we prepared a
global IPv4 network through SA46T. From the afternoon of September
7th 2011, we additionally provided a private IPv4 network through
4RD.
Hazeyama & Ueno Expires April 26, 2012 [Page 5]
Internet-Draft Abbreviated Title October 2011
+--------+ +-----------+
|SA46T-GW|--(v4)----+ |v6tunnel-gw|
| |--(v6)-+ | +-----------+
+--------+ | | |(v6) |(v6)
+----------------------------------+ +---+
+-----------| router |--(dual)--|DNS|
| +----------------------------------+ +---+
| | |(v6) |(v4)
| | +--------+
(v6) (dual) | NAT64 |
| | +--------+
| +---------+ +---------------+
| | WIDE BB |-(v4)-| IPv4 Internet |
| +---------+ +---------------+
| |(v6)
| +---------------+
| | IPv6 Internet |
+---------+ +---------------+
|satellite| |(v6)
+---------+ +-------+
| | ONU |
| +-------+
| |(v6)
| +-------------+
| | v6tunnel-gw |
| +-------------+
| |(v6)
| +--------+ +-----+
+-----------------| router |--(v6)--|DNS64|
+--------+ +-----+
|(v6) |
+-----+ +--------+ | +-----+
|DHCP4| |SA46T-GW| (v6) |DHCP6|
+-----+ +--------+ | +-----+
|(v4) |(v4) | |(v6)
----------------- user access -----------------
The Basic Network Topology.
Figure 1
3.1. The IPv6-Only Network
Here, we explain the basic configurations on the IPv6-Only network on
the WIDE camp.
Hazeyama & Ueno Expires April 26, 2012 [Page 6]
Internet-Draft Abbreviated Title October 2011
3.1.1. External Links
Figure. 1 shows the basic network topology of the WIDE camp autumn
2011. We announced the IPv6 and IPv4 addresses on the conference
network from the WIDE backbone's address block. The conference
network had two IPv6-Only external lines; one was an IPv6-Only
network through a portable satellite base station, the other was an
IPv6 Internet service on a FTTH line.
On the FTTH line, we set up an IPv6 tunnel between the hotel and Keio
university Shonan Fujisawa Campus (SFC). The main user access VLAN
was routed through this line, both the IPv6 network and the IPv4
network by SA46T. We tested two types of IPv6 services provided by
NTT East as an access carrier, Internet MultiFeed as a virtual
network enabler, and IIJ as an IPv6 ISP. The IPv6 network on the
FTTH external line was served through Native method
[YasudaAPRICOT2011]. From 2:00 PM of September 5th to 8:00 PM of
September 6th (JST), we used a Flet' s Hikari Next with IPv6 option.
The IPv6 address on the v6tunnel gateway were assigned from RA with
/64 prefix. From 8:00 PM of September 6th (JST), we changed the
setting of the external line service to a Flet's Hikari Next with
IPv6 option and a Hikari phone option, for the 4RD experiment, as
drawn in Figure 2. The differences brought by Hikari phone option
were as follows; i) an additional home gateway was added, ii) the
IPv6 address delegation method was changed from RA with /64 prefix
length to DHCP6[RFC3736] with /48 prefix length.
On the other hand, the satellite line directly connected between the
router on the hotel and the router on SFC. The satellite line
transferred another IPv6 network VLAN.
3.1.2. IPv6 Tunnel
For the IPv6 routing by WIDE Project's IPv6 address block, we
achieved an L2TP tunnel between the v6-tunnel gateway on the
Matsushiro and that on SFC over the FTTH line. The v6-tunnel
gateways were composed of Linux Debian squeeze (kernel 2.6.32)
servers with our original L2TP for IPv6 implementation.
3.1.3. DHCP6
Global IPv6 addresses for users and the DNS64 address were provided
through ISC's DHCP6 implementation [ISC-DHCP]. A user cloud
automatically get the IPv6 connectivity through the IPv6 Router
Advertisement Options for DNS Configuration[RFC6106], if the DHCP6
implementation on the user's device worked well. Otherwise, a user
had to set up DNS64 address as a resolver by manual.
Hazeyama & Ueno Expires April 26, 2012 [Page 7]
Internet-Draft Abbreviated Title October 2011
3.1.4. DNS64 and NAT64
We used linuxnat64 [linuxnat64] as the NAT64 implementation. DNS64
was built by ISC bind 9.8-p4 [bind]. As shown in Figure 1, we placed
a DNS64 server on the hotel, on the other hand, NAT64 severs were
settled on SFC side.
3.2. The IPv4 Networks
3.2.1. The IPv4 Network through SA46T
As a last resort for IPv6 incapable OSes, devices and applications,
we prepared an global IPv4 network through SA46T. We used a software
implementation of SA46T developed by Fujitsu and Keio university. To
conduct the capability tests of NAT64, DNS64 and DHCP6, the global
IPv4 network was served as an option. A global IPv4 address was
assigned to a user's device by registering the device's MAC address
on a registration web page. We hid the registration web page from
participants until 1:00 PM of September 7th (JST) to pursue the
capability tests of NAT64, DNS64 and DHCP6.
3.2.2. The IPv4 Network through 4RD
We also held the capability test of 4RD implementations. On the
midnight of September 6th, we reconstructed the external link as
shown in Figure 2 to convey 4RD encapsulated packets. The 4RD-BR on
the SFC side was composed of a vyatta 4RD implementation
[vyatta-4RD]. On the hotel side, we used IIJ's SEIL 4RD
implementation [SEIL] as 4RD gateway and 4RD-BR and 4RD-CE. We
started the 4RD experiment to participants at 3:15 PM of September
7th (JST). The 4RD-CE provided a private IPv4 network by DHCP4 and
an IPv6 network by RA. The resolver was served through the DHCP4
function of the 4RD-CE.
Hazeyama & Ueno Expires April 26, 2012 [Page 8]
Internet-Draft Abbreviated Title October 2011
+--------+ +-----------+ +---------+
|SA46T-GW|--(v4)----+ |v6tunnel-gw| +---(v4)--| 4RD-BR |
| |--(v6)-+ | +-----------+ | +-(v6)--| (vyatta)|
+--------+ | | |(v6) |(v6) | | +---------+
+----------------------------------+ +---+
+-----------| router |--(dual)-|DNS|
| +----------------------------------+ +---+
| | |(v6) |(v4)
| | +--------+
(v6) (dual) | NAT64 |
| | +--------+
| +---------+ +---------------+
| | WIDE BB |-(v4)-| IPv4 Internet |
| +---------+ +---------------+
| |(v6)
| +---------------+
| | IPv6 Internet |
+---------+ +---------------+
|satellite| |(v6)
+---------+ +-------+ +---+ +-------+ +------+
| | ONU |-(v6)-|HGW|-(v6)-|4RD-BR |-(v6)-|4RD-CE|
| +-------+ +---+ |(SEIL) | |(SEIL)|
| +-------+ +------+
| +-------------+ | |
| | v6tunnel-gw |--(v6)----+ ---user access---
| +-------------+ (v6 / private v4)
| |(v6)
| +--------+ +-----+
+-----------------| router |---(v6)---|DNS64|
+--------+ +-----+
|(v6) |
+-----+ +--------+ | +-----+
|DHCP4| |SA46T-GW| (v6) |DHCP6|
+-----+ +--------+ | +-----+
|(v4) |(v4) | |(v6)
----------------- user access -------------------
The Network Topology with 4RD.
Figure 2
4. Experiences from the Experiments
4.1. Answers of Questionnaire
Here, we reports the answers of questionnaire about the experiments.
Hazeyama & Ueno Expires April 26, 2012 [Page 9]
Internet-Draft Abbreviated Title October 2011
4.1.1. The distributions of connectivities that participants used
Table. 1 shows the distributions of used connectivities which
participants answered. 30 participants (19.6%) surely lived in the
IPv6 only connectivity with NAT64 / DNS64 during the all conference
days. 7 participants, who used the v6 connectivity and the v4
connectivity through SA46T, were such participants who came to the
NOC team in September 6th for the NOC team's help to be assigned the
IPv4 connectivity. 33 participants, who replied that he / she used
the IPv4 connectivity served by 4RD but did not use the IPv4
connectivity through SA46T, were such persons that needed the IPv4
connectivity but would not want to register his / her MAC address to
be registered. 34 participants, who used both SA46T and 4RD IPv4
connectivity, would join the comparison test between SA46T and 4RD.
+-------------------+--------------------------------+
| Connectivities | # of participants (percentage) |
+-------------------+--------------------------------+
| v6 only | 30 (19.6 %) |
| v6 only + SA46T | 7 (4.5 %) |
| v6 + 4RD | 33 (21.5 %) |
| v6 + SA46T + 4RD | 34 (22.2 %) |
| avoidance to ans. | 6 (3.9 %) |
| No response | 43 (28.1 %) |
+-------------------+--------------------------------+
Table 1: The distributions of connectivities that participants used
4.1.2. The satisfaction on the IPv6 only connectivity
Table. 2 shows the satisfaction of participants about the IPv6 only
connectivity. Different from the expectation by the NOC team, 90
participants (58.8%) were satisfied in the IPv6 only connectivity.
Especially, Windows 7 users and Mac OS X 10.7 (Lion) users were
likely to reply good impressions because their DHCP6 functions worked
well. On the other hand, older OS users, Layer 3 VPN users (IPSec,
PPTP) and / or non-XMPP IM users were tend to escape into IPv4
connectivities.
From the free comments on questionnaire, many users were surprised
that the availability of the IPv6 only connectivity with NAT64 and
DNS64 were much more comfortable than that they thought.
Hazeyama & Ueno Expires April 26, 2012 [Page 10]
Internet-Draft Abbreviated Title October 2011
+-------------------+--------------------------------+
| Satisfaction | # of participants (percentage) |
+-------------------+--------------------------------+
| Very Comfortable | 19 (12.4 %) |
| Comfortable | 52 (33.9 %) |
| Satisfactory | 20 (13.0 %) |
| Inconvenient | 13 (8.4 %) |
| Unbearable | 3 (1.9 %) |
| avoidance to ans. | 3 (1.9 %) |
| No response | 43 (28.1 %) |
+-------------------+--------------------------------+
Table 2: The satisfaction on the IPv6 only connectivity
4.1.3. The satisfaction on the network quality
Table. 3 shows distributions of answers about the satisfaction on the
total network quality. 92 participants (60.1 %) were satisfied with
the quality on the conference network. Most of 15 participants, who
answered inconvenient or unbearable, were such participants who had
to log-in their companies or organizations' intranets through Layer 3
tunnels by IPv4 to read e-mails.
+-------------------+--------------------------------+
| Satisfaction | # of participants (percentage) |
+-------------------+--------------------------------+
| Very Comfortable | 14 (9.1 %) |
| Comfortable | 57 (37.2 %) |
| Satisfactory | 21 (13.7 %) |
| Inconvenient | 13 (8.4 %) |
| Unbearable | 2 (1.3 %) |
| avoidance to ans. | 3 (1.9 %) |
| No response | 43 (28.1 %) |
+-------------------+--------------------------------+
Table 3: The quality on the network
4.2. Reported Troubles
Here, we summarize the reported troubles on the availability on the
IPv6 network and IPv4 networks through SA46T and 4RD.
4.2.1. Troubles on the IPv6 capability of OSes and Devices
Reported troubles on the IPv6 capability of OSes were as follows.
Hazeyama & Ueno Expires April 26, 2012 [Page 11]
Internet-Draft Abbreviated Title October 2011
4.2.1.1. Pains due to long fallback routine
Most commercial OSes checked IPv4 connectivity when the IPv4 property
were enabled. The fallback routine spent a few minutes. Many
participants claimed why the initial network setting consumed a few
minutes and how to solve it. The long fall back routine was easily
solved by turning off the IPv4 property on each OS. The NOC team
provided several manuals for turning off / turning on the IPv4
property in several OSes.
4.2.1.2. Pains due to lack of DHCP6 capability
Older version OSes such as Mac OS X 10.6 (snow leopard) and older did
not have DHCP6 capability. Such users had to set up the DNS64
resolver address in manual. Several novice users were bothered with
setting up the DNS resolver settings and requested the NOC team
support to set up it.
4.2.1.3. Pains due to the OS's incapability on IPv6 only setting
Windows XP could not work without the IPv4 property, therefore,
Windows XP users had to set up a local proxy to resolve AAAA records
through IPv4 localhost IPv4 address (127.0.0.1). These settings were
difficult for most Windows XP users, many participants were tend to
give up the IPv6 settings. Several participants contributed TIPS or
setting instructions for such Windows XP users.
Android OS needed the IPv4 property on resolving names.
4.2.1.4. Pains due to the device's incapability for IPv6
Several devices, such as Apple's USB RJ45 Ethernet Port, did not have
the IPv6 capability. Also, some participant reported he had to
reinstall device drivers again and again.
4.2.1.5. Failure of settings through GUI
Some Mac Book Air user met the IPv6 settings disappeared in a few
minutes after he set the IPv6 settings through GUI. Also, Think Pad'
network setting manager could not set up IPv6 only setting through
GUI appropriately. These failure of settings could be solved by
setting through CLI commands.
4.2.2. Troubles on Applications
Three kinds of troubles on applications were reported to the NOC
team.
Hazeyama & Ueno Expires April 26, 2012 [Page 12]
Internet-Draft Abbreviated Title October 2011
4.2.2.1. Pains due to IPv6 incapability on applications
As well as Arkko's report on IETF IPv6 only connectivity experiments
[I-D.draft-arkko-ipv6-only-experience], most non-XMPP based IM
applications and VoIP applications did not work. Skype and Window
live messenger users claimed to the NOC team that they wanted or had
to use such IMs in their business.
Several applications on Windows did not work, such as CVSNT, NOD32
signature updates. In Mac OS X, non-COCOA framework applications did
not work well.
On the other hand, Most HTTP/XMPP based applications or
communications were available or worked well, expect for such HTTP/
XMPP based applications that might use IPv4 literals.
4.2.2.2. Failures due to incapability of protocol translation between
IPv4 and IPv6
IPSec-based applications, such as OpenVPN or Apple Mobile Me IPSec
and PKI based communications, did not work on the 6to4 connections.
PPTP clients did not work, too. Also, some FTP clients did not work
well on the v6 only connectivity with NAT64 / DNS64 and on the 4RD
IPv4 connectivity.
4.2.2.3. Failures due to MTU mismatch problems
During the setup on Sep. 5th, the NOC team met MTU problems. Several
servers were hosted on the cloud (KVM) environment on the WIDE
backbone (the WIDE Cloud). Basically, the WIDE Cloud backbone MTU
size was set 9000 for rapid live migration, however, MTU 9000 setting
on KVM hyper-visors collapsed various communications in the set up
day (Sep. 5th). Therefore, we set the MTU size of KVM hyper-visors
to 1500.
According to answers of questionnaire and reported troubles, various
UDP based communications, such as a Remote KVM function of CISCO UCS
server, did not still work well by MTU mismatch problems, not only on
the NAT64 / DNS64 environment, but also on the SA46T's 464
encapsulation. The NOC team could not find the actual MTU mismatch
points during the conference days.
4.2.3. Troubles on Name Resolution
The NOC team met several troubles on Name Resolution. Some of them
were derived from typical mis-configurations.
Hazeyama & Ueno Expires April 26, 2012 [Page 13]
Internet-Draft Abbreviated Title October 2011
4.2.3.1. Failures due to IPv4 address literals
As well as Arkko's report on IETF IPv6 only connectivity experiments,
failures due to IPv4 address literals occurred. Many participants
claimed they could not access to their IPv4 servers by IPv4 address
literals through HTTP, SSH, VNC, IPSec, PPTP, IMAP, SMTP, and so on.
Some of them were fixed by changing IPv4 address literals to name
literals on the settings of their applications and / or by
registering their IPv4 servers in DNS records. However, most of
participants were not the administrators of their IPv4 servers or DNS
servers. Thus, most of them escaped to the IPv4 connectivity served
from the afternoon of Sep. 7th.
On the VNC, PPTP, IPSec and other VPN communications, many
participants claimed that several applications did not work well both
on IPv4 only servers and on IPv6 capable servers even when they
changed the access manners to name literals. Those access failures
might be affected by incapability for IPv6/IPv4 translation on VPN
protocols or MTU mismatch problems against UDP based communications.
4.2.3.2. Failures due to lack of reverse lookup entries on AAAA records
In the hot stage days, the NOC team detected several commercial web
pages could not be accessed due to failure of reverse lookup.
Therefore, we registered all reverse lookup AAAA records on the
camp.wide.ad.jp domains.
4.2.3.3. Failures due to the lame delegation
As mentioned above, some commercial web sites required the reverse
lookup in AAAA records as well as in A records. Several participants
claimed some commercial web pages cloud not be seen by failure of
reverse lookup, although we registered all reverse lookup entries in
AAAA about the camp.wide.ad.jp domain. We investigated the causes of
the failure of reverse lookup, the cause was the lame delegation on
the upper authoritative server of the DNS64 server (ns.wide.ad.jp)
brought by a mis-configuration of bind. After the lame delegation
was solved by an operator of ns.wide.ad.jp, problems on reverse
lookup were fixed.
4.2.3.4. Pains due to the overload of DNS64
In September 8th, the NOC team changed the configuration of DNS64 to
enable DNSSEC functions. After enabling DNSSEC, the DNS64 server,
which was placed on a KVM virtual machine on the Matsushiro Royal
hotel, was overwhelmed by handling many queries and key
verifications. Then, participants hardly accessed to IPv4 Internet
with DNS64.
Hazeyama & Ueno Expires April 26, 2012 [Page 14]
Internet-Draft Abbreviated Title October 2011
Therefore, the NOC team moved the DNS64 server from the KVM
environment to a physical server, then, the overload on the DNS64
server was solved.
4.2.3.5. Failures due to inappropriate AAAA replies
Different from the IETF's experiment, the accessibility test of web
pages were conducted by manual, that is, by actual web access of
participants. Some web pages, especially search result pages of
travel reservation sites, could not access from the IPv6 network
through NAT64 / DNS64 translation. The reasons why connections to
such web pages failed were derived from inappropriate DNS replies
mentioned in [RFC4074].
We observed ``Return Name Error'' mentioned in Section 4.2 of
[RFC4074], ``Return Other Erroneous Codes'' in Section 4.3 of
[RFC4074], and Return a Broken Response in Section 4.4 [RFC4074],
respectively. We could not solve these problems in the conference
days because these problems were derived from wrong behaviors of DNS
resolvers on the web sites.
5. Lessons from the experiences on the WIDE camp
Here, we describe lessons or recommendations from the experiences on
the WIDE camp for building or living in an IPv6 environment with
NAT64 and DNS64.
o You SHOULD implement or enable the IPv6 capability into your site
soon if it is possible, because NAT or NAPT environments might
cause various problems such as MTU mismatch, low throughput,
incapability on translation, and so on. Actually, some partner
organizations of the WIDE project requested IPv6 address blocks
soon after the WIDE camp.
o You SHOULD update or purchase OSes on your computers to the latest
version, because Window 7 users and Mac OS X 10.7 (Lion) users did
not meet critical troubles, and because older OS users met various
troubles.
o You WOULD be better to register reverse AAAA lookup entries,
because several commercial web sites require the reverse lookup.
o You SHOULD give sufficient resources to a DNS64 server, because
the failure or overload of DNS64 server are critical for the
accessibility to IPv4 Internet from IPv6 only network.
Hazeyama & Ueno Expires April 26, 2012 [Page 15]
Internet-Draft Abbreviated Title October 2011
o You SHOULD check whether your web / DNS appliances return
inappropriate AAAA replies or not, because some web appliances
might return inappropriate AAAA replies and inappropriate AAAA
replies can be solved by only administrators on web sites.
o You SHOULD take care of MTU size on multiple overlaid underlay
networks because PMTUD might not work in some times.
6. Open Issues
6.1. PMTUD, MTU mismatch problems
On the camp-net experiments, PMTUD, MTU mismatch problems occurred in
several points. The NOC team and experiment team could not
completely fix all MTU mismatch problems, therefore, several
participants could not use UDP communications, such as a remote KVM
function of a CISCO UCS server, through the conference network or VPN
tunnels.
These problems were mainly derived from the failure of Path MTU
Discovery. In the operational problem to avoid the overload of
routers or DDoS attacks, man y networks turn off PMTUD functions on
routers. However, many applications or implementations of tunneling
/ encapsulation protocols assume that the PMTUD would work.
6.2. Inappropriate AAAA replies
Inappropriate DNS replies pointed in [RFC4074] are one of open issues
on the IPv6 transitions. Ideally, vendors SHOULD implement web / DNS
appliances with taking care of [RFC4074] and network operators SHOULD
replace all AAAA resolvers to appropriate AAAA resolvers. However,
such solution will spend money, human resources, and time to
deployment. A possible immediate solution is changing the fallback
routines of DNS64 resolvers as follows;
o A DNS64 resolver resolves the A record even when a DNS reply
contained NXDOMAIN or ServFail.
o A DNS64 resolver caches all possible A records. When a DNS reply
was NOERROR, the DNS64 resolver queries the AAAA record. If the
AAAA record exists, then the DNS64 resolver returns the AAAA
record to a client, and if not, the DNS64 resolver returns the
cached A record to the client.
These solutions would be required further discussion in appropriate
working group.
Hazeyama & Ueno Expires April 26, 2012 [Page 16]
Internet-Draft Abbreviated Title October 2011
7. Conclusion and Future Work
This experiment was the first time of WIDE Project on availability
test of the IPv6 only connectivity with participants. Many
participants replied good impressions, however, various issues were
clarified through this experiment. We would like to store TIPS to
operate the IPv6 only connectivity not only through the regular
experiment on the WIDE camp, and also through the daily operation of
the IPv6 only connectivity on the WIDE backbone.
8. Security Considerations
As well as Arkko mentioned in
[I-D.draft-arkko-ipv6-only-experience-03], the use of IPv6 instead of
IPv4 by itself does not make a big security difference. In our
experience, we only set up following security functions; the access
control list on routers / servers, DNSSEC, accounting on the wireless
network access.
9. IANA Considerations
This document has no IANA implications.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
Hazeyama & Ueno Expires April 26, 2012 [Page 17]
Internet-Draft Abbreviated Title October 2011
10.2. Informative References
[I-D.draft-arkko-ipv6-only-experience]
Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", April 2011, <draft-arkko-ipv6-only-experience-03
(work in progress)>.
[I-D.draft-matsuhira-sa46t-applicability]
Matsuhira, N., "Applicability of Stateless automatic IPv4
over IPv6 Tunneling (SA46T)", July 2011,
<draft-matsuhira-sa46t-applicability-02 (work in
progress)>.
[I-D.draft-matsuhira-sa46t-as]
Matsuhira, N., "Stateless Automatic IPv4 over IPv6
Tunneling with IPv4 Address Sharing", April 2011,
<draft-matsuhira-sa46t-as-01 (work in progress)>.
[I-D.draft-matsuhira-sa46t-gaddr]
Matsuhira, N., "Stateless Automatic IPv4 over IPv6
Tunneling: Global SA46T Address Format", July 2011,
<draft-matsuhira-sa46t-gaddr-03 (work in progress)>.
[I-D.draft-matsuhira-sa46t-mcast]
Matsuhira, N., "SA46T Multicast Support", September 2011,
<draft-matsuhira-sa46t-mcast-00 (work in progress)>.
[I-D.draft-matsuhira-sa46t-motivation]
Matsuhira, N., "Motivation for developing Stateless
Automatic IPv4 over IPv6 Tunneling (SA46T)", July 2011,
<draft-matsuhira-sa46t-motivation-00 (work in progress)>.
[I-D.draft-matsuhira-sa46t-spec]
Matsuhira, N., "Stateless Automatic IPv4 over IPv6
Tunneling: Specification", July 2011,
<draft-matsuhira-sa46t-spec-03 (work in progress)>.
[I-D.draft-murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "Stateless
Automatic IPv4 over IPv6 Tunneling: Specification",
September 2011, <draft-murakami-softwire-4rd-01 (work in
progress)>.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers", October 2010,
<draft-ietf-behave-dns64-11 (work in progress)>.
Hazeyama & Ueno Expires April 26, 2012 [Page 18]
Internet-Draft Abbreviated Title October 2011
[I-D.ietf-behave-ftp64]
Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation",
March 2011, <draft-ietf-behave-ftp64-08 (work in
progress)>.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", August 2010,
<draft-ietf-behave-v6v4-framework-10 (work in progress)>.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", September 2010,
<draft-ietf-behave-v6v4-xlate-23 (work in progress)>.
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", July 2010,
<draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress)>.
[ISC-DHCP]
Internet Systems Consortium., "DHCP",
<http://www.isc.org/software/dhcp>.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[SEIL] Internet Initiative Japan, "SEIL", September 2011,
<http://www.seil.jp/>.
[YasudaAPRICOT2011]
Yasuda, A., "Building for IPv6 by IPv6 Promotion Council
Japan.", February, 2011, <http://meetings.apnic.net/
__data/assets/pdf_file/0003/30981/
Ayumu-Yasuda-apricot.pdf>.
[bind] Internet Systems Consortium., "BIND",
<http://www.isc.org/software/bind>.
[linuxnat64]
Geeknet, Inc., "Linux NAT64 implementation",
<http://linuxnat64.sourceforge.net/>.
Hazeyama & Ueno Expires April 26, 2012 [Page 19]
Internet-Draft Abbreviated Title October 2011
[vyatta-4RD]
masakazu, "masakazu's weblog (In Japanese)", June 2011,
<http://bougaidenpa.org/masakazu/archives/176>.
Appendix A. Acknowledgements
Here, we thank to 153 participants of WIDE camp 2011 autumn on this
experiments. We also say thank you to N. Matsuhira of Fujitsu for
the SA46T implemnetation, H. Suenaga and K. Ooyatsu of IIJ for SEIL
4RD implementation, NTT EAST, Internet Multifeed, and IIJ for serving
the commercial IPv6 Internet service for this experiment on the
Matsushiro Royal Hotel.
Authors' Addresses
Hiroaki Hazeyama
NAIST
Takayama 8916-5
Nara,
Japan
Phone: +81 743 72 5216
Email: hiroa-ha@is.naist.jp
Yukito Ueno
Keio Univ.
5322 Endo
Kanagawa,
Japan
Email: eden@sfc.wide.ad.jp
Hazeyama & Ueno Expires April 26, 2012 [Page 20]