One document matched: draft-hazeyama-widecamp-ipv6-only-experience-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!--
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
-->
<!--
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
-->
<!-- NAT -->
<!ENTITY RFC2663 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!-- source address selection -->
<!--
<!ENTITY RFC3484 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml">
-->
<!-- DHCP6 -->
<!ENTITY RFC3736 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736.xml">
<!-- Basic transition mechanism / dual stack -->
<!ENTITY RFC4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!-- IPv6 Router Advertisement Options for DNS configurations -->
<!ENTITY RFC6106 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6106.xml">
<!-- DNS64 -->
<!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!-- ipv6 addressing for translator -->
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!-- NAT64 for XLAT -->
<!-- framework for nat64 -->
<!ENTITY RFC6144 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6144.xml">
<!-- IP/ICMP Translation algorithm -->
<!ENTITY RFC6145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
<!-- stateful NAT64 -->
<!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY RFC6384 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6384.xml">
<!-- wrong DNS -->
<!ENTITY RFC4074 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4074.xml">
<!--- NAT Behavioral Requirements for Unicast UDP --->
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!--- STUN --->
<!ENTITY RFC5389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!--- STUN --->
<!ENTITY RFC5780 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5780.xml">
<!--- TURN --->
<!ENTITY RFC5766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml">
<!--- IPoE --->
<!ENTITY RFC0894 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml">
<!--- PPPoE --->
<!ENTITY RFC2516 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2516.xml">
<!--- v4 linklocal --->
<!ENTITY RFC3927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml">
<!--- v4 linklocal assumption --->
<!ENTITY RFC4943 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4943.xml">
<!--- v4 linklocal assumption --->
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<!--
<rfc category="info" docName="draft-hazeyama-widecamp-ipv6-only-experience-01" ipr="trust200902">
-->
<rfc category="info" docName="draft-hazeyama-widecamp-ipv6-only-experience-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IPv6 Experiments in the WIDE Camp">
Experiences from IPv6-Only Networks with Transition Technologies
in the WIDE Camp Spring 2012
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Hiroaki Hazeyama" initials="H."
surname="Hazeyama">
<organization>NAIST</organization>
<address>
<postal>
<street>Takayama 8916-5</street>
<!-- Reorder these if your country does things differently -->
<city>Nara</city>
<region></region>
<code></code>
<country>Japan</country>
</postal>
<phone>+81 743 72 5216</phone>
<email>hiroa-ha@is.naist.jp</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ruri Hiromi" initials="R."
surname="Hiromi">
<organization>Intec Inc.</organization>
<address>
<postal>
<street>1-3-3 Shin-Suna, Koutou</street>
<!-- Reorder these if your country does things differently -->
<city>Tokyo</city>
<region></region>
<code></code>
<country>Japan</country>
</postal>
<email>hiromi@inetcore.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tomohiro Ishihara" initials="T."
surname="Ishihara">
<organization>Univ. of Tokyo</organization>
<address>
<postal>
<street>3-8-1 Komaba, Meguro</street>
<!-- Reorder these if your country does things differently -->
<city>Tokyo</city>
<region></region>
<code></code>
<country>Japan</country>
</postal>
<email>sho@c.u-tokyo.ac.jp</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Osamu Nakamura" initials="O."
surname="Nakamura">
<organization>WIDE Project</organization>
<address>
<postal>
<street>5322 Endo</street>
<!-- Reorder these if your country does things differently -->
<city>Kanagawa</city>
<region></region>
<code></code>
<country>Japan</country>
</postal>
<email>osamu@wide.ad.jp</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Operation and Management</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>IPv6 Only network, NAT64, DNS64, DHCP6, SA46T, 4RD</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<!--The original specification of xml2rfc format is in <xref
target="RFC2629">RFC 2629</xref>.
-->
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.
</t>
<section title="History of ``Live with IPv6 experiment'' on the WIDE camp">
<t> ``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.
</t>
<section title="Summary of the 1st experiment">
<t>
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 <xref target="I-D.draft-arkko-ipv6-only-experience"></xref>, we reported several new issues on an IPv6 only network with IPv4 / IPv6 transition technologies, especially on inappropriate DNS replies mentioned in <xref target="RFC4074"></xref>, on MTU mismatch, on VPN protocols and applications through IPv4 / IPv6 translators.
</t>
</section>
<section title="Abstract of the 2nd experiment">
<t>
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, 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.
</t>
<t>
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<xref target="RFC0894"></xref> on NTT NGNv6 (we name it ``native IPoE'' in this draft), the other was /56 prefix IPv6 network service through PPPoE<xref target="RFC2516"></xref> on NTT NGNv6 (we label it ``native PPPoE'' in this draft)<xref target="YasudaAPRICOT2011"></xref>. Both IPv6 networks were served from NTT-East, Internet MultiFeed and IIJ as same as the 1st experiment.
</t>
<t>
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<xref target="RFC3736"></xref><xref target="RFC6106"></xref> both on native IPoE and on native PPPoE.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC4074"></xref>, 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.
</t>
</section>
</section>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Technology and Terminology">
<t>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 <xref target="RFC2663"></xref>.
</t>
<t>"Dual Stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers <xref target="RFC4213"></xref>.</t>
<t> "NAT64" refers to a Network Address Translator - Protocol Translator defined in <xref target="RFC6052"></xref>,
<xref target="RFC6144"></xref>,
<xref target="RFC6145"></xref>,
<xref target="RFC6146"></xref>,
<xref target="RFC6147"></xref>,
<xref target="RFC6384"></xref>.
</t>
<t> "SA46T" refers to Stateless Automatic IPv4 over IPv6 Tunneling defined in
<xref target="I-D.draft-matsuhira-sa46t-motivation"></xref>,
<xref target="I-D.draft-matsuhira-sa46t-as"></xref>,
<xref target="I-D.draft-matsuhira-sa46t-spec"></xref>,
<xref target="I-D.draft-matsuhira-sa46t-gaddr"></xref>,
<xref target="I-D.draft-matsuhira-sa46t-applicability"></xref>,
<xref target="I-D.draft-matsuhira-sa46t-mcast"></xref>.
</t>
<t>"4RD" refers to IPv4 Residual Deployment on IPv6 Infrastructure defined in <xref target="I-D.draft-murakami-softwire-4rd"></xref>.</t>
<t>"464XLAT" refers to Combination of Stateful and Stateless Translation defined in <xref target="I-D.draft-ietf-v6ops-464xlat"></xref>.
</t>
</section>
<section title="Network and Experiment Setup">
<t>
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 <xref target="topology_overview"></xref> shows the overview of the test topology on the 2nd experiment, and Figure <xref target="topology_ipoe"></xref> and Figure <xref target="topology_pppoe"></xref> represent details of the network in Matsushiro Royal Hotel.
</t>
<t>
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 network equipment vendor (NEC AccessTechnica) and a SIer (NTT Advanced Technology).
</t>
<figure align="center" anchor="topology_overview">
<artwork align="left"><![CDATA[
+-----------------------------------------------+
| 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) |
+------------------------------------------------------------+
]]></artwork>
<postamble> Over view of the 2nd experiment topology </postamble>
</figure>
<figure align="center" anchor="topology_ipoe">
<artwork align="left"><![CDATA[
+----------------+
| 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
]]></artwork>
<postamble> The Test Topology on NTT NGNv6 IPoE service </postamble>
</figure>
<figure align="center" anchor="topology_pppoe">
<artwork align="left"><![CDATA[
+-------------------+
| 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
]]></artwork>
<postamble> The Test Topology on NTT NGNv6 PPPoE service </postamble>
</figure>
<section title="IPv6 networks">
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section> <!--- end of IPv6 networks -->
<section title="IPv4 networks">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref target="SEIL"></xref>. The 4RD network was operated by IIJ.
</t>
<t>
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 <xref target="RFC6145"></xref>, and DNS v4/v6 proxy.
</t>
<t>Each transition technology has limitation on available protocols,
fragmentation support, and so on. One of purposes of this 2nd experiment was to grasp these limitations and reasons of each limitation.
</t>
</section> <!--- end of IPv4 networks -->
<section title="DNS Settings">
<t>
Table <xref target="table_dns"></xref> 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.
</t>
<t>
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 <xref target="RFC4074"></xref>. 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<texttable anchor="table_dns" title="DNS settings">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Network</ttcol>
<ttcol align="center">DNS settings </ttcol>
<!--- Dual Stack --->
<c>Dual Stack, Manual settings for older OSes</c>
<c>203.178.159.53, 2001:200:0:ff60::53 (DNS load balance)</c>
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!--- LISP --->
<c>LISP</c>
<c>2001:200:0:ff60::6 (DNS64)</c>
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!--- L3 mesh --->
<c>L3 mesh</c>
<c>2001:200:0:ff60::6 (DNS64)</c>
<!--- blank --->
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!-- native IPoE -->
<c>native IPoE</c>
<c>2001:200:0:ff60::53 (DNS load balance)</c>
<!--- blank --->
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!-- native PPPoE -->
<c>native PPPoE</c>
<c>2001:200:0:ff60::53 (DNS load balance)</c>
<!--- blank --->
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!--- SA46T --->
<c>SA46T (SA46T-FA, SA46T-FK)</c>
<c>203.178.159.53 (DNS load balance)</c>
<!--- blank --->
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!--- 4RD --->
<c>4RD (4RD/IPoE, 4RD/PPPoE)</c>
<c> 210.130.1.1 (via proxy)</c>
<!--- blank --->
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!--- 464XLAT/IPoE --->
<c>464XLAT/IPoE</c>
<c>2404:1a8:7f01:b::3 (primary), 2001:4860:4860::8888 (secondary) </c>
<!--- blank --->
<c> -------------------------- </c>
<c> ------------------------------------ </c>
<!--- 464XLAT/PPPoE --->
<c>464XLAT/PPPPoE</c>
<c>2001:240::13 (primary), 2001:4860:4860::8888 (secondary) </c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
</section> <!--- end of DNS settings -->
<section title="NAT64 Settings">
<t>
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.
</t>
</section> <!--- end of NAT64 settings -->
<section title="Wireless networks">
<t> 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 <xref target="table_wifi"></xref> 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).
</t>
<t>
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.
</t>
<texttable anchor="table_wifi" title="Time Slot of served networks through layer 2 mesh Wi-Fi">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Time Slot</ttcol>
<ttcol align="center">ESSID 1 </ttcol>
<ttcol align="center">ESSID 2 </ttcol>
<ttcol align="center">ESSID 3 </ttcol>
<ttcol align="center">ESSID 4 </ttcol>
<!--- until 17:30 3/5 --->
<c>13:00 Mar. 5th to 17:30 Mar. 5th</c>
<c>464XLAT/IPoE</c>
<c>4RD/IPoE</c>
<c>native IPoE</c>
<c> - </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--- 17:30 3/5 - 12:00 3/6 --->
<c>18:00 Mar. 5th to 12:00 Mar. 6th </c>
<c>native IPoE</c>
<c>native PPPoE</c>
<c>4RD/PPPoE</c>
<c> - </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--- 17:30 3/5 - 12:00 3/6 --->
<c>12:30 Mar. 6th to 17:30 Mar. 6th </c>
<c>L3 mesh (IPv6)</c>
<c>SA46T-FA</c>
<c>464XLAT/PPPoE</c>
<c>native IPoE </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--- 18:00 3/6 - 12:00 3/7 --->
<c>18:00 Mar. 6th to 12:00 Mar. 7th </c>
<c>native PPPoE</c>
<c>464XLAT/IPoE</c>
<c>SA46T-FK</c>
<c> - </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--- 18:00 3/6 - 12:00 3/7 --->
<c>12:30 Mar. 7th to 17:30 Mar. 7th </c>
<c>native PPPoE</c>
<c>4RD/IPoE</c>
<c>native IPoE</c>
<c> - </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--- 18:00 3/6 - 12:00 3/7 --->
<c>18:00 Mar. 7th to 5:00 Mar. 8th </c>
<c>4RD/PPPoE with closed IPv6</c>
<c>4RD/IPoE on IEEE 11b </c>
<c>native IPoE</c>
<c> rogue </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--- 18:00 3/6 - 12:00 3/7 --->
<c>5:00 Mar. 8th to 12:00 Mar. 8th</c>
<c>dual stack (WIDE)</c>
<c> - </c>
<c> - </c>
<c> - </c>
<c> ---------- </c>
<c> ------------ </c>
<c> ------------ </c>
<c> ------------- </c>
<c> ------ </c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
</section> <!--- end of wifi networks -->
<section title="Settings for MTU and NAT / Firewall Traversal Tests for commercial (P2P) Network Games">
<t>
Evaluating MTU and NAT / Firewall Traversal Tests on each test network for commercial (P2P) Network Games, Konami Digital Entertainment (KDE) experiment team placed STUN <xref target="RFC5389"></xref> and TURN <xref target="RFC5766"></xref> 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.
</t>
</section> <!--- end of konami's test -->
</section> <!-- end of section 2 --->
<section title="Experiences from the Experiments">
<section title="User Survey by face-to-face interview">
<t>
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.
</t>
<t>
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.
</t>
<section title="Client Profile">
<t>
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. <xref target="table_devices"></xref> shows distributions of Devices.
Table. <xref target="table_oses"></xref> 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.
</t>
<texttable anchor="table_devices" title="The distributions of devices of participants">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Devices</ttcol>
<ttcol align="center"># of participants (percentage) </ttcol>
<c>Personal Computer</c>
<c>140 (47.1 %)</c>
<c> ----------------- </c>
<c>------------------------------ </c>
<c>Tablet PC </c>
<c>23 (7.7 %)</c>
<c> ----------------- </c>
<c>------------------------------ </c>
<c>Smart Phone </c>
<c>114 (38.4 %)</c>
<c> ----------------- </c>
<c>------------------------------ </c>
<c>Game Devices </c>
<c>19 (6.4 %)</c>
<c> ----------------- </c>
<c>------------------------------ </c>
<c> Others </c>
<c> 1 (0.3 %) </c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<texttable anchor="table_oses" title="The distributions of Operating Systems on participants' devices">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">OS</ttcol>
<ttcol align="center"># of devices (percentage) </ttcol>
<c>Android </c>
<c>37 (12.5 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Android 2.2 </c>
<c>2 (9.7 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Android 2.3 </c>
<c>3 (1.0 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Android 2.3.4 </c>
<c>2 (0.7 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Android 4.0.2 </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Android 4.0.3 </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Arch Linux </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>blackberry </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>CentOS </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Debian </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>FreeBSD </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>iOS 4.3.2 JB </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>iPad iOS </c>
<c>21 (7.1 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>iPhone iOS </c>
<c>59 (19.9 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>iPod Touch iOS </c>
<c>11 (3.7 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Kindle </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Linux Open WRT 2.7.39 </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Mac OS X Lion </c>
<c>48 (16.2 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Mac OS X Snow Leopard </c>
<c>31 (10.4 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>NetBSD 5.1 </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Nokia 5800 </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>PSP </c>
<c>2 (0.7 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>PS Vita </c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Ubuntu </c>
<c>4 (1.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>WiMAX Router</c>
<c>1 (0.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Windows Vista </c>
<c>4 (1.3 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Windows XP </c>
<c>11 (3.7 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Windows 7 </c>
<c>35 (11.8 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Windows Mobile </c>
<c>3 (1.0 %)</c>
<c> ------------------------- </c>
<c> ------------------------- </c>
<c>Nintendo DS / 3DS (0.3 %)</c>
<c>3 (1.0 %)</c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
</section> <!-- end of client profile -->
<section title="Reported Troubles">
<t>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.
</t>
<section title="Failure of IPv6 neighbor discovery due to the on-link assumption of IPv4 network">
<t>
In the IPv6 single stack LAN, although 169.254/16 IPv4 Link Local Address<xref target="RFC3927"></xref> was assigned to an interface, some devices tried to get IPv4 address by DHCP4 and failed IPv6 neighbor discovery due to 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.
</t>
<t>
The similar harmful behavior on IPv6 Neighbor Discovery along with on-link assumption in IPv4 only network has been described in <xref target="RFC4943"></xref>. We need further evaluation and discussion on this IPv4 case.
</t>
</section><!-- failure of ND -->
<section title="Locked out IPv6 by vendor">
<t>
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.
</t>
</section><!-- locked out IPv6 -->
<section anchor="mis_on_dns" title="Inappropriate selection of DNS resolvers">
<t>
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 <xref target="RFC4193"></xref>) was used, it might be getting more complicated.
</t>
</section> <!--- operational failure with DNS resolvers -->
<section title=" Previous configuration lived after moving to another WiFi network">
<t>
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 <xref target="mis_on_dns"></xref>) occurred at the same time.
</t>
</section>
<section title="Crash of an application by plug-in">
<t>
An IPv4 depended plugin crashed an application. Unawareness of dual stack for application programmers may occur serious problems before IPv6 deployment. It is more important to share what is dual stack network and functions for dual stack communications.
</t>
</section>
<section title="Happy Eyeball implementation with turn-on/off switch">
<t>
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.
</t>
<t>
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.
</t>
<!---
<t>
For example, the default value of "network.http.fast-fallback-to-IPv4" is true in Firefox10.
Many of average / novice users would not change its value then it might become an obstacle on the IPv6 deployment.
</t>
--->
</section> <!-- Happy Eyeball -->
<section title="Different behavior among OSes on MTU handling">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref target="konamicheck"></xref>. Therefore, we could not remove the influence from lack of fragmentation support of one of SA46T implementation.
We have to verify difference of behaviors on packet fragmentation among OSes with further experiments.
</t>
</section>
</section> <!-- reported troubles -->
</section> <!-- End of user survey -->
<section anchor="konamicheck" title="MTU and NAT Traversal Tests for Network Games">
<t>
Here, we explain the result of MTU and NAT Traversal Tests by KDE experiment team. The test patterns were designed according to <xref target="RFC4787"></xref> as follows;
<list style="symbols">
<t> Address and Port Mapping Behavior</t>
<t>Port Assignment Behavior</t>
<t>Filtering Behavior</t>
<t>Hairpinning Behavior</t>
<t>Fragmentation of Outgoing Packets</t>
<t>Receiving Fragmented Packets</t>
</list>
</t>
<t>
These items were tested by KDE's test clients through STUN protocols defined in <xref target="RFC5389"></xref> and in <xref target="RFC5780"></xref>. Clients sent UDP packets to the STUN server along with test scenarios.
</t>
<section title="Between a Client and the STUN Server">
<t>
Table <xref target="table_test_elements"></xref> shows test items by a client. Table <xref target="table_test_cs_native"></xref>, Table <xref target="table_test_cs_4rd"></xref>, Table <xref target="table_test_cs_464xlat"></xref> and Table <xref target="table_test_cs_sa46t"></xref> shows MTU and NAT Traversal test results on each network.
</t>
<t> The SA46T results in Table <xref target="table_test_cs_464xlat"></xref> and Table <xref target="table_test_cs_sa46t"></xref> derived from the difference among implementations on fragment support function.
</t>
<!--- table for test items --->
<texttable anchor="table_test_elements" title="Test Elements of NAT, Mapping, Filtering ( RFC 4787 ) / RTT / MTU">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Elements</ttcol>
<ttcol align="center">Definition </ttcol>
<c>NAT </c>
<c>Exist: NAT exists, - : no NAT </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>Mapping </c>
<c>Good or Bad : Good / Bad Behavior for P2P Game </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>Filtering </c>
<c>Good or Bad : Good / Bad Behavior for P2P Game </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>RTT </c>
<c>Round Trip Time (msec.) </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>MTU size from client to server </c>
<c>size (byte) </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>Fragmentation from client to server </c>
<c>OK or NG : whether a big packet (DF=0) can be sent from a client to the server with fragmentation or not. </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>MTU size from server to client </c>
<c>size (byte) </c>
<c> ---------------- </c>
<c> ---------------------------------------------- </c>
<c>Fragmentation from server to client </c>
<c>YES or NO : whether a big packet (DF=0) can be sent from the server to a client with fragmentation or not. </c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<!--- table for native IPv6 --->
<texttable anchor="table_test_cs_native" title="NAT Traversal Test Results between a Client and STUN Server (global IPv6)">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Elements</ttcol>
<ttcol align="center">native PPPoE (v6) </ttcol>
<ttcol align="center">native IPoE (v6) </ttcol>
<c>NAT </c>
<c> - </c> <!-- native PPPoE -->
<c> - </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Mapping </c>
<c> - </c> <!-- native PPPoE -->
<c> - </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Filtering </c>
<c> - </c> <!-- native PPPoE -->
<c> - </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>RTT </c>
<c> 117 </c> <!-- native PPPoE -->
<c> 75 </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>MTU size C => S </c>
<c> 1452 </c> <!-- native PPPoE -->
<c> 1500 </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Frag. C => S </c>
<c> YES </c> <!-- native PPPoE -->
<c> YES </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>MTU size S => C </c>
<c>1500 </c> <!-- native PPPoE -->
<c>1500 </c> <!-- native IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Frag. S => C </c>
<c> YES </c> <!-- native PPPoE -->
<c> YES </c> <!-- native IPoE -->
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<!---- Table for 4RD ---->
<texttable anchor="table_test_cs_4rd" title="NAT Traversal Test Results between a Client and STUN Server on 4RD">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Elements</ttcol>
<ttcol align="center">4RD/PPPoE (v4)</ttcol>
<ttcol align="center">4RD/IPoE (v4)</ttcol>
<c>NAT </c>
<c>Exist </c> <!-- 4RD/PPPoE -->
<c>Exist </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Mapping </c>
<c>Bad </c> <!-- 4RD/PPPoE -->
<c>Good </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Filtering </c>
<c>Good </c> <!-- 4RD/PPPoE -->
<c>Good </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>RTT </c>
<c>156 </c> <!-- 4RD/PPPoE -->
<c>323 </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>MTU size C => S </c>
<c>1452 </c> <!-- 4RD/PPPoE -->
<c>1452 </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Frag. C => S </c>
<c> NO </c> <!-- 4RD/PPPoE -->
<c> NO </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>MTU size S => C </c>
<c>1280 </c> <!-- 4RD/PPPoE -->
<c>1452 </c> <!-- 4RD/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Frag. S => C </c>
<c> YES </c> <!-- 4RD/PPPoE -->
<c> YES </c> <!-- 4RD/IPoE -->
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<texttable anchor="table_test_cs_464xlat" title="NAT Traversal Test Results between a Client and STUN Server on 464XLAT">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Elements</ttcol>
<ttcol align="center">464XLAT/PPPoE (v4)</ttcol>
<ttcol align="center">464XLAT/IPoE (v4)</ttcol>
<c>NAT </c>
<c>Exist </c> <!-- 464XLAT/PPPoE -->
<c>Exist </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Mapping </c>
<c>Good </c> <!-- 464XLAT/PPPoE -->
<c>Good </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Filtering </c>
<c>Good </c> <!-- 464XLAT/PPPoE -->
<c>Good </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>RTT </c>
<c>119 </c> <!-- 464XLAT/PPPoE -->
<c>464 </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>MTU size C => S </c>
<c>1260 </c> <!-- 464XLAT/PPPoE -->
<c>1476 </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Frag. C => S </c>
<c> YES </c> <!-- 464XLAT/PPPoE -->
<c> YES </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>MTU size S => C </c>
<c>1260 </c> <!-- 464XLAT/PPPoE -->
<c>1480 </c> <!-- 464XLAT/IPoE -->
<c> --------------- </c>
<c> ----------------- </c>
<c> ---------------- </c>
<c>Frag. S => C </c>
<c> YES </c> <!-- 464XLAT/PPPoE -->
<c> YES </c> <!-- 464XLAT/IPoE -->
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<texttable anchor="table_test_cs_sa46t" title="NAT Traversal Test Results between a Client and STUN Server on SA46T">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Elements</ttcol>
<ttcol align="center">SA46T-FA (v4)</ttcol>
<ttcol align="center">SA46T-FK (v4)</ttcol>
<c>NAT </c>
<c> - </c> <!-- SA46T-FA -->
<c> - </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>Mapping </c>
<c> - </c> <!-- SA46T-FA -->
<c> - </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>Filtering </c>
<c> - </c> <!-- SA46T-FA -->
<c> - </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>RTT </c>
<c>112 </c> <!-- SA46T-FA -->
<c>76 </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>MTU size C => S </c>
<c>1460 </c> <!-- SA46T-FA -->
<c>1460 </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>Frag. C => S </c>
<c> YES </c> <!-- SA46T-FA -->
<c> NO (lack of frag. func. on SA46T-FK) </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>MTU size S => C </c>
<c> NO (lack of frag. func. on SA46T-KO) </c> <!-- SA46T-FA -->
<c> NO (lack of frag. func. on SA46T-KO) </c> <!-- SA46T-FK -->
<c> --------------- </c>
<c> ---------------------- </c>
<c> ---------------------- </c>
<c>Frag. S => C </c>
<c> NO (due to SA46T-KO) </c> <!-- SA46T-FA -->
<c> NO (due to SA46T-KO) </c> <!-- SA46T-FK -->
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
</section> <!-- Between a Client and the STUN Server -->
<section title="Between Clients with NAT">
<texttable anchor="table_test_cc" title="P2P connectivity between Clients on each IPv6 or IPv4 network">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center"> Network </ttcol>
<ttcol align="center"> Protocol </ttcol>
<ttcol align="center"> Connectivity </ttcol>
<c> native PPPoE </c>
<c> IPv6 </c>
<c> Good (no NAT) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------- </c>
<c> native IPoE </c>
<c> IPv6 </c>
<c> Good (no NAT) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------------------------------- </c>
<!--- 4RD/PPPoE --->
<c> 4RD/PPPoE </c>
<c> IPv4 </c>
<c> Bad (Address and Port dependent mapping) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------------------------------- </c>
<!--- 4RD/IPoE --->
<c> 4RD/IPoE </c>
<c> IPv4 </c>
<c> Bad (no hairpinning) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------------------------------- </c>
<!--- 464XLAT/PPPoE --->
<c> 464XLAT/PPPoE </c>
<c> IPv4 </c>
<c> Bad (no hairpinning) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------------------------------- </c>
<!--- 464XLAT/IPoE --->
<c> 464XLAT/IPoE </c>
<c> IPv4 </c>
<c> Bad (no hairpinning) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------------------------------- </c>
<!--- SA46T-FA --->
<c> SA46T-FA </c>
<c> IPv4 </c>
<c> Good (no NAT) </c>
<c> ----------- </c>
<c> ----------- </c>
<c> ----------------------------------- </c>
<!--- SA46T-FK --->
<c> SA46T-FK </c>
<c> IPv4 </c>
<c> Good (no NAT) </c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
</section> <!-- Between Clients with NAT -->
</section> <!-- konami's experiment -->
<section title="Analysis of inappropriate authoritative servers from DNS64 Log ">
<t>
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 <xref target="RFC4074"></xref>.
Also, <xref target="RFC6147"></xref> says
<list>
<t>
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.
</t>
<t>
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.
</t>
</list>
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.
</t>
<t>
The name server settings of the camp were as follows;
<list>
<t> F5 BIG-IP forwarded queries to DNS64 server except ``www.camp.wide.ad.jp''. </t>
<t>DNS64 server only forwarded queries to Unbound/BIND resolver and did not do any iterative queries by itself </t>
<t> We have changed target resolver from bind server to unbound server at midnight on March 5th </t>
</list>
We analyzed DNS64's error messages recorded in March 5th when DNS64 forwarded queries to the BIND resolver. Table <xref target="table_bind"></xref> 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 <xref target="table_unbound"></xref>. 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.
</t>
<t>
Table <xref target="table_total"></xref> 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.
</t>
<texttable anchor="table_bind" title="The distributions of error messages">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Error Type</ttcol>
<ttcol align="center"># of unique authoritative servers </ttcol>
<c>Refused</c>
<c>47 </c>
<c> ----------------- </c>
<c>------------------------------ </c>
<c>ServFail</c>
<c>66</c>
<c> ----------------- </c>
<c>------------------------------ </c>
<c>FormError </c>
<c>554</c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<texttable anchor="table_unbound" title="Verification FormError of BIND by Unbound">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center">Error Type</ttcol>
<ttcol align="center"># of unique auth. servers (BIND) </ttcol>
<ttcol align="center"># of unique auth. servers (Unbound) </ttcol>
<c>NXDOMAIN</c>
<c>449 </c>
<c>21 </c>
<c> --------- </c>
<c> --------- </c>
<c> --------- </c>
<c>NOERROR Record = 0</c>
<c>66</c>
<c>506</c>
<c> --------- </c>
<c> --------- </c>
<c> --------- </c>
<c>NOERROR Record > 0 </c>
<c>9</c>
<c>7</c>
<c> --------- </c>
<c> --------- </c>
<c> --------- </c>
<c>Others (ex. no reply) </c>
<c>11</c>
<c>20</c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
<texttable anchor="table_total" title="Statistics of DNS through the camp">
<!-- <preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
-->
<ttcol align="center"></ttcol>
<ttcol align="center"> number </ttcol>
<c># of names (A, AAAA, PTR, SRV(</c>
<c>70886 </c>
<c> --------- </c>
<c> --------- </c>
<c># of names queried by AAAA</c>
<c>45633</c>
<c> --------- </c>
<c> --------- </c>
<c># of NXDOMAIN by AAAA from Unbound </c>
<c>4011</c>
<c> --------- </c>
<c> --------- </c>
<c># of names which A record exist althogh an auth. server returned NXDOMAIN by AAAA from Unbound</c>
<c>69</c>
<c># of NXDOMAIN by AAAA from Unbound </c>
<c>4011</c>
<c> --------- </c>
<c> --------- </c>
<c># of NXDOMAIN by AAAA from BIND </c>
<c>4234</c>
<c> --------- </c>
<c> --------- </c>
<c># of names which A record exist althogh an auth. server returned NXDOMAIN by AAAA from BIND</c>
<c>201</c>
<!--
<postamble>which is a very simple example.</postamble>
-->
</texttable>
</section> <!-- DNS64 log -->
</section> <!-- experiment-->
<!---
<section title="Lessons from the experiences on the WIDE camp">
</section>
--->
<section title="Open Issues">
<section title="Dependency between IPv4 and IPv6 address configuration">
<t>
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.
</t>
</section>
<section title="PMTUD, MTU mismatch problems and NAT behavior problems">
<t>
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.
</t>
<t>
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.
</t>
<t> 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.
</t>
<!---
<t>
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.
</t>
--->
</section>
<section title="Workaround for DNS64 problems">
<t>
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.
</t>
<section anchor="wa-rcode3" title="Workaround for illegal NameError">
<t>
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.
</t>
</section>
<section anchor="wa-servfail" title="Workdaround for lame delegation">
<t>
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 record is cached same as section <xref target="wa-rcode3"></xref>. 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.
</t>
</section>
</section>
</section>
<section title="Conclusion and Future Work">
<t>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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
As well as Arkko mentioned in <xref target="I-D.draft-arkko-ipv6-only-experience"></xref>,
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.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document has no IANA implications.
</t>
</section>
<!--
<section anchor="Acknowledgments" title="Acknowledgments">
<t>Here, we thank to 153 participants on this experiments.</t>
</section>
-->
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2663; <!-- NAT -->
&RFC3736; <!-- DHCP6 --> <!-- no ref in middle -->
&RFC4213; <!-- ??? -->
&RFC6106; <!-- ??? --> <!-- no ref in middle -->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!--
&RFC2629;
&RFC3552;
&RFC5226;
-->
&RFC4074; <!-- inappropriate AAAA replies -->
&RFC6052;
&RFC6144;
&RFC6145;
&RFC6146;
&RFC6147;
&RFC6384;
&RFC4787;
&RFC5389;
&RFC5766;
&RFC5780;
&RFC0894;
&RFC2516;
&RFC3927;
&RFC4943;
&RFC4193;
<!-- A reference written by by an organization not a person. -->
<reference anchor="YasudaAPRICOT2011"
target="http://meetings.apnic.net/__data/assets/pdf_file/0003/30981/Ayumu-Yasuda-apricot.pdf">
<front>
<title>Building for IPv6 by IPv6 Promotion Council Japan.</title>
<author fullname="Ayumu Yasuda" initials="A." surname="Yasuda">
<organization>NTT East</organization>
</author>
<date year="February, 2011" />
<keyword>http://meetings.apnic.net/__data/assets/pdf_file/0003/30981/Ayumu-Yasuda-apricot.pdf</keyword>
</front>
</reference>
<reference anchor="I-D.draft-arkko-ipv6-only-experience"
target="draft-arkko-ipv6-only-experience-05 (work in progress)">
<front>
<title> Experiences from an IPv6-Only Network</title>
<author initials="J." surname="Arkko"></author>
<author initials="A." surname="Keranen"></author>
<date year="Febrary 2012" />
<keyword>draft-arkko-ipv6-only-experience-05 (work in progress)</keyword>
</front>
</reference>
<!-- references for SA46T -->
<reference anchor="I-D.draft-matsuhira-sa46t-as"
target="draft-matsuhira-sa46t-as-01 (work in progress)">
<front>
<title>Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing</title>
<author initials="N." surname="Matsuhira"></author>
<date year="April 2011" />
<keyword> draft-matsuhira-sa46t-as-01 (work in progress)</keyword>
</front>
</reference>
<reference anchor="I-D.draft-matsuhira-sa46t-gaddr"
target="draft-matsuhira-sa46t-gaddr-03 (work in progress)">
<front>
<title> Stateless Automatic IPv4 over IPv6 Tunneling: Global SA46T Address Format</title>
<author initials="N." surname="Matsuhira"></author>
<date year="July 2011" />
<keyword> draft-matsuhira-sa46t-gaddr-03 (work in progress)</keyword>
</front>
</reference>
<reference anchor="I-D.draft-matsuhira-sa46t-mcast"
target="draft-matsuhira-sa46t-mcast-00 (work in progress)">
<front>
<title> SA46T Multicast Support</title>
<author initials="N." surname="Matsuhira"></author>
<date year="September 2011" />
<keyword> draft-matsuhira-sa46t-mcast-00 (work in progress)</keyword>
</front>
</reference>
<reference anchor="I-D.draft-matsuhira-sa46t-motivation"
target="draft-matsuhira-sa46t-motivation-00 (work in progress)">
<front>
<title> Motivation for developing Stateless Automatic IPv4 over IPv6 Tunneling (SA46T)</title>
<author initials="N." surname="Matsuhira"></author>
<date year="July 2011" />
<keyword> draft-matsuhira-sa46t-motivation-00 (work in progress)</keyword>
</front>
</reference>
<reference anchor="I-D.draft-ietf-v6ops-464xlat"
target="draft-ietf-v6ops-464xlat-01 (work in progress)">
<front>
<title> 464XLAT: Combination of Stateful and Stateless Translation</title>
<author initials="M." surname="Mawatari"></author>
<author initials="M." surname="Kawashima"></author>
<author initials="C." surname="Byrne"></author>
<date year="March 2012" />
<keyword> draft-ietf-v6ops-464xlat-01 (work in progress)</keyword>
</front>
</reference>
<reference anchor="I-D.draft-matsuhira-sa46t-applicability"
target="draft-matsuhira-sa46t-applicability-02 (work in progress)">
<front>
<title> Applicability of Stateless automatic IPv4 over IPv6 Tunneling (SA46T)</title>
<author initials="N." surname="Matsuhira"></author>
<date year="July 2011" />
<keyword> draft-matsuhira-sa46t-applicability-02 (work in progress)</keyword>
</front>
</reference>
<reference anchor="I-D.draft-matsuhira-sa46t-spec"
target="draft-matsuhira-sa46t-spec-04 (work in progress)">
<front>
<title>Stateless Automatic IPv4 over IPv6 Tunneling: Specification</title>
<author initials="N." surname="Matsuhira"></author>
<date year="January 2012" />
<keyword> draft-matsuhira-sa46t-spec-04 (work in progress)</keyword>
</front>
</reference>
<!-- reference to 4RD -->
<reference anchor="I-D.draft-murakami-softwire-4rd"
target="draft-murakami-softwire-4rd-01 (work in progress)">
<front>
<title>Stateless Automatic IPv4 over IPv6 Tunneling: Specification</title>
<author initials="T." surname="Murakami"></author>
<author initials="O." surname="Troan"></author>
<author initials="S." surname="Matsushima"></author>
<date year="September 2011" />
<keyword>draft-murakami-softwire-4rd-01 (work in progress)</keyword>
</front>
</reference>
<!-- references to software -->
<reference anchor="SEIL"
target="http://www.seil.jp/">
<front>
<title>SEIL</title>
<author>
<organization> Internet Initiative Japan </organization>
</author>
<date year="September 2011" />
</front>
</reference>
<!--
<reference anchor="bind"
target="http://www.isc.org/software/bind">
<front>
<title>BIND</title>
<author>
<organization> Internet Systems Consortium. </organization>
</author>
</front>
</reference>
-->
<!--
<reference anchor="ISC-DHCP"
target="http://www.isc.org/software/dhcp">
<front>
<title>DHCP</title>
<author>
<organization> Internet Systems Consortium. </organization>
</author>
</front>
</reference>
-->
<!--
<reference anchor="linuxnat64"
target="http://linuxnat64.sourceforge.net/">
<front>
<title>Linux NAT64 implementation</title>
<author>
<organization>Geeknet, Inc.</organization>
</author>
</front>
</reference>
-->
</references>
<section anchor="app-additional" title="Acknowledgments">
<!--
<t>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 implementation, 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.</t>
-->
<t>
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.
</t>
<t>
N. Matsuhira of Fujitsu for SA46T.
</t>
<t>
R. Nakamura of Keio Univ. for SA46T.
</t>
<t>
H. Suenaga and K. Ooyatsu of IIJ for SEIL 4RD.
</t>
<t>
JPIX and M. Kawashima of NEC AccessTechnica for 464XLAT.
</t>
<t>
NTT-AT guys for providing BIG-IP and Pivot3, which does load balancing, DNS64, NAT64, and capturing all traffic.
</t>
<t>
Y. Ueno of Keio Univ. for IPv6 L2TP implementation.
</t>
<t>
R. Sato and M. Sato of Konami Digital Entertainment Co, Ltd. for NAT/Firewall traversal testing.
</t>
<t>
NTT EAST, Internet Multifeed, and IIJ for the commercial IPv6 service.
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:28:49 |