Internet Engineering Task Force J. Tan
Internet-Draft J. Lin
Intended status: Informational W. Li
Expires: September 8, 2011 China Telecom
March 7, 2011
Experience from NAT64 applications
draft-tan-v6ops-nat64-experiences-00
Abstract
This document discusses our experiences from deploying NAT64 devices
for various Internet applications. Before the final transition to an
IPv6-only network, NAT64 is one of the possible technologies which
may be used to give users access to the IPv4-only parts of the
Internet via an IPv6-only network. This document analyzes the
testing results for a number of popular applications and describes
the problems to be solved in the period of transition from IPv4 to
IPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 8, 2011.
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
Tan, et al. Expires September 8, 2011 [Page 1]
Internet-Draft Experience from NAT64 applications March 2011
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Network Topology Setup . . . . . . . . . . . . . . . . . . . . 3
3. Experiences With Various Use Cases . . . . . . . . . . . . . . 4
3.1. Web Applications . . . . . . . . . . . . . . . . . . . . . 4
3.2. Email Client . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Instant Messaging . . . . . . . . . . . . . . . . . . . . . 5
3.4. Peer-to-Peer (P2P) Applications . . . . . . . . . . . . . . 6
3.5. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6.1. Stream Media Player . . . . . . . . . . . . . . . . . . 6
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Tan, et al. Expires September 8, 2011 [Page 2]
Internet-Draft Experience from NAT64 applications March 2011
1. Introduction
This document discusses our experiences from deploying NAT64
[I-D.ietf-behave-v6v4-xlate-stateful] devices for various Internet
applications, both traditional and new. The main conclusion is that
it is possible to deploy NAT64 devices at the edge of IPv6-only
networks, but there are a number of issues unsolved such as lack of
IPv6 support in PPTP and VPN connections.
Note: Since no NAT64 and DNS64 devices are available for the time
being, NAT-PT was used instead. Tests were run both with DNS-ALG
enabled and with DNS-ALG disabled.
2. Network Topology Setup
The operating system we tested was Microsoft Windows 7 and the tested
applications are the currently updated version. The IPv6 prefix was
delegated as 2001:c68:100:100::/64, while the global IPv6 address was
configured via SLAAC. The NAT-PT device was connected to the edge
router of CNGI (China Next Generation Internet). A static route was
configured in this device to direct packets destined to prefix 2001:
c68:100:2:: (the prefix for the IPv6 DNS server) to the NAT-PT
device.
In the NAT-PT device, the IPv4 addresses of the target websites or
servers were mapped to global IPv6 addresses through dynamic or
static mappings. When the tested terminal sent packets to these
global IPv6 addresses, they were routed to the NAT-PT device which
performed protocol translation and address translation.
The address of IPv6 DNS server was manually configured to 2001:c68:
100:2:1::ca61:6, with the DNS-ALG enabled at the NAT-PT device. The
AAAA DNS query from the terminal was transformed to an A query to the
ISP's IPv4 DNS cache server via NAT-PT translation. We also
implemented a dual-stack DNS cache server and added AAAA entries for
the tested websites. The global IPv6 addresses of those websites are
based on the NAT-PT's prefix and its IPv4 public addresses. The
terminal has been setup the DNS server address as the IPv6 address of
this dual-stack DNS cache server while the DNS-ALG is disabled at
NAT-PT.
The NAT Log information was acquired by remote monitoring. The logs
contained the 5-tuple, set up time and end-up time. The traffic Log
was manually exported.
Tan, et al. Expires September 8, 2011 [Page 3]
Internet-Draft Experience from NAT64 applications March 2011
3. Experiences With Various Use Cases
This section discusses specific issues with various applications and
appliances. Issues to be solved are also described.
3.1. Web Applications
All HTTP/HTTPs based web browsers, i.e., comprehensive portal
website, webmail,search engine and HTTP download, that we have tried
so far seem to work well without problems. When the DNS-ALG option
of NAT-PT is enabled and AAAA record request is not restrained, we
can visit websites which have AAAA records in the public DNS, e.g.,
ipv6.google.com. The address is the "real" IPv6 address. However,
if an IPv6 host initiates an AAAA record request for some website,
e.g., www.abc.com, but there is no corresponding AAAA record in the
DNS, the IPv4 version of the website cannot normally be visited since
the DNS-ALG does not convert this AAAA record request to an A record
request. On the other hand, while the DNS-ALG option is enabledand
the AAAA record request is restrained, we can visit the website or
servers without IPv6 address by NAT-PT and DNS-ALG, but we cannot get
the IPv6 address of the IPv6/Dual-stack websites or servers when the
AAAA DNS record requests go through the NAT-PT.
HTTP downloading via domain name works well normally, for example, to
upload and download HTTP netdisk service. However, problems exist in
thosee file sharing websites which have policies based on source IP
addresses. In that case, downloading does not work correctly and the
users who are sharing a public IPv4 address needs to wait for a very
long time before starting download from the same website at the same
time. In addition, for some website resources which are downloaded
directly without DNS query, downloading does not work as well.
Especially when the website redirects the users to a separate IPv4
server by telling the browser the IPv4 address rather than the domain
name of the server.
We also tested with some new web applications, e.g., Web-based video,
Online music, Blog, SNS, Online shopping and Web-based map. Most
popular video sharing websites in China do not support NAT-PT because
the video resource is normally stored separately and the web server
or application server redirects the resources' IPv4 address to the
user-end Flash player plug-in, which is not translated to an IPv6
address when it goes through the NAT-PT device.
Actually, whether using domain name lookup or connecting by address
directly to the source depends on the content of the website,
security policy and website provided, security policies and its
software and hardware architecture. It may be not easy to change the
existing architecture which makes the transition of such kind of
Tan, et al. Expires September 8, 2011 [Page 4]
Internet-Draft Experience from NAT64 applications March 2011
websites difficult and complex.
Blogs on most websites appear to work fine except for one webpage
style and layout problem at blog.163.com. We believe that is because
the CSS file is not loaded correctly.
E-bank web plug-in and client (software) do not work well with NAT-PT
devices because the client end usually communicates directly with the
server using a known IPv4 address. Even though the client performs a
domain name lookup procedure, most of the client cannot recognize the
translated IPv6 address. Besides, there is usually a logging server
for security purpose that may not recognize IPv6 addresses and may
not identify and distinguish users by the shared IPv4 address.
Google maps display normally when the browser opens six windows/tabs
of maps simultaneously to watch different sites. The sessions are
limited separately to 250 and 50 in this testing.
3.2. Email Client
The impact of NAT64 on email protocols (POP3, SMTP and IMAP) worked
normally. The Microsoft Live Mail 2011 and Microsoft Office Outlook
support IPv6, while Foxmail 6.5 does not. But there may be a little
problem. Users can only wait for a new version of the software and
access their email account via webmail during the transition period.
3.3. Instant Messaging
We have tested several instance messaging applications in an IPv6-
only network with NAT64 and the test results can be found in Table 1.
System Status
QQ2010 client NOT OK
WebQQ OK
Windows Live Messenger NOT OK
Ebuddy Web OK
Fetion NOT OK
Skype NOT OK
Table 1: Instant Messaging Applications in an IPv6-Only Network
Most of the instant messaging systems tested were not able to log
onto the server, by reason of lacking IPv6 support in the clients.
However, the web-based instant messaging sysytem works well, and may
be considered as a transition tool for the instant messaging systems
with a large number of clients before the new versions are released.
Tan, et al. Expires September 8, 2011 [Page 5]
Internet-Draft Experience from NAT64 applications March 2011
3.4. Peer-to-Peer (P2P) Applications
Each Peer-to-Peer (P2P) downloading software displays downloading
resources on the information page, employing HTTP as transport. From
the experiments we have done, most P2P software packages do not
support IPv6, e.g., we failed to get connection with peers from
BitComet. There are also P2P clients that claim to support IPv6,
like uTorrent and emule. However, we did not succeed when trying to
make IPv6 connections. The problem is probably that the peers'
addresses of the contents stored in tracker server are mainly IPv4
addresses. When these addresses sent from the Tracker to the
downloading peer is encapsulated in the payload,it cannot be
translated when it passes through the NAT-PT device. As a result,
even though the uTorrent client of an IPv6 host and the Tracker
server support IPv6, the client still can not download IPv4 resources
from IPv4 peers via NAT64 device.
3.5. Gaming
Another application we have tested is online games. We cannot log in
to most gaming platforms unless they uses domain name. It is
presumably because the game client does not support IPv6. We cannot
make further experiments before the IPv6-supported clients are
released.
3.6. VPN
The VPN testing is to estimate whether the VPN client can initial a
connection to the remote access server through a NAT64 device. The
testing is based on Windows Vista (as the VPN client) and Windows
Server 2008 R2 Standard (as the RAAS). Two protocols were applied to
connect to the remote access server: L2TP/IPSec and PPTP. The
results show that the PPTP protocol does not support IPv6 while L2TP/
IPSec technology supports IPv. However, the Internet Key Exchange
failed when passing through the NAT64.
3.6.1. Stream Media Player
Other applications we have tested include online stream media player
software (e.g. PPTV, PPStream, UUSee), third Party FTP client and
Remote cooperation/assistant tools (e.g. pcAnywhere and Windows
Remote Desktop). The online stream media player can download the
playlist and advertisements normally, but it was unable to connect to
the media server and play the media contents.
Tan, et al. Expires September 8, 2011 [Page 6]
Internet-Draft Experience from NAT64 applications March 2011
4. Conclusions
This document discusses our experiences from deploying NAT64 devices
for various Internet applications. The main conclusion is that two
problems exist from our experimention. First is the weakness of the
IPv6 capability of user end clients, and the second problem is that
the IPv4 addresses can not be translated when they are carried inside
a packet's payload.
5. Security Considerations
None.
6. Informative References
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers (Work in progress)", July 2010.
Authors' Addresses
Jinghua Tan
China Telecom
109, Zhongshan Ave. West,
Tianhe District, Guangzhou 510630
P.R. China
Phone:
Email: tanjh@gsta.com
Jinyan Lin
China Telecom
109, Zhongshan Ave. West,
Tianhe District, Guangzhou 510630
P.R. China
Phone:
Email: jasonlin.gz@gmail.com
Tan, et al. Expires September 8, 2011 [Page 7]
Internet-Draft Experience from NAT64 applications March 2011
Weibo Li
China Telecom
109, Zhongshan Ave. West,
Tianhe District, Guangzhou 510630
P.R. China
Phone:
Email: MWeiboLI@gmail.com
Tan, et al. Expires September 8, 2011 [Page 8]