draft-chen-v6ops-nat64-experience-02

Aleksi Suhonen <Aleksi.Suhonen@tut.fi> Fri, 06 July 2012 07:41 UTC

Return-Path: <Aleksi.Suhonen@tut.fi>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9192721F8749 for <ipv6@ietfa.amsl.com>; Fri, 6 Jul 2012 00:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-QfRF06PYIp for <ipv6@ietfa.amsl.com>; Fri, 6 Jul 2012 00:41:23 -0700 (PDT)
Received: from mail-gw-out2.cc.tut.fi (mail-gw-out2.cc.tut.fi [130.230.160.33]) by ietfa.amsl.com (Postfix) with ESMTP id 03A7B21F8738 for <ipv6@ietf.org>; Fri, 6 Jul 2012 00:41:22 -0700 (PDT)
X-AuditID: 82e6a021-b7f236d000000a82-7f-4ff696b0080f
Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw-out2.cc.tut.fi (Symantec Messaging Gateway) with SMTP id 74.FE.02690.0B696FF4; Fri, 6 Jul 2012 10:41:36 +0300 (EEST)
Received: from [IPv6:2001:708:310:52:21a:6bff:fe61:167] (pool46.nat64.trex.fi [195.140.194.46]) by mail1.tut.fi (Postfix) with ESMTPSA id D1AD840135; Fri, 6 Jul 2012 10:41:36 +0300 (EEST)
Message-ID: <4FF696AA.3050508@tut.fi>
Date: Fri, 06 Jul 2012 10:41:30 +0300
From: Aleksi Suhonen <Aleksi.Suhonen@tut.fi>
Organization: Tampere University of Technology / Department of Communications Engineering
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5
MIME-Version: 1.0
To: sunqiong@ctbri.com.cn, niu.qibo@zte.com.cn
Subject: draft-chen-v6ops-nat64-experience-02
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrIIsWRmVeSWpSXmKPExsXS9GyRsO7Gad/8DT4yWbw8+57J4kNnC6vF n89v2B2YPeY8es/qsWTJTyaPNft+sAQwR3HZpKTmZJalFunbJXBl3Pp7n7HgIl9F4828BsZb 3F2MnBwSAiYSz15OZ4WwxSQu3FvP1sXIxSEksI9RorXtFzOEc4BRYtetrUAZDg5eAVWJ7Vt1 QRpYgMymc0dZQGw2AR2JK1232EBsfoFoidfn/rKD2KICIRLTmw8ygdi8AoISJ2c+AasXEdCT mNd7jhnEZgaKPzv8gxVkvLCArsSf9+YQYRuJvycWsUDY8hLb385hnsDIPwvJpFlIymYhKVvA yLyKUSw3MTNHN71cN7+0xEgvOVmvpLRELy1zEyM4HBco7mA8NUP/EKMAB6MSD29mwjd/IdbE suLK3EOMkhxMSqK8qZOBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4ezO++gvxpiRWVqUW5cOk ZDg4lCR4WYCxIyRYlJqeWpGWmQOMOpg0EwcnSDsPUPurqUA1vMUFibnFmekQ+VOMilLivA9B EgIgiYzSPLheUMzX/////xWjONCxwrwMICt4gOkCrvsV0GAmoMF5iz+BDC5JREhJNTDudNh4 fk7g6tT9h7gqPjk1PQnes2vCsbOnls3ZqtgcqJwYtULF6sDGDrZ/3MfaupXXG2hI9zJfD608 65ltfEpy5qofjwo3d33webM7aH+XyFUZV8H02RKrTu5ZtubTlW+yJ77WBV644Cq15+bX1LaV al/4bH8q3tXc1XZZ0O3vacsalw9WfrsclViKMxINtZiLihMByNn/odQCAAA=
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2012 07:41:24 -0000

Hi,

We've been running a NAT64/DNS64 setup at TREX Tampere Region Exchange 
for over a year now and I'd like to submit the following experience for 
your draft:

IPv6 Privacy Extensions are a big problem with stateless NAT64. A single 
device with priv exts enabled will use up several IPv4 addresses from 
the NAT64 pool. And since the IPv4 Internet is full of malware probing 
for vulnerabilities, the whole IPv4 address pool for the stateless NAT64 
will periodically get random traffic from the Internet.

Even if the priv ext addresses have expired, the network will generate 
an ICMPv6 unreachable message which will travel through the NAT64 device 
and thus refresh timers for the IPv4 mapping. Some firewalls will also 
generate TCP RST messages for such probes to non-existent IPv6 addresses.

In fact, our worst experience has been with an Apple iPad which was left 
alone in an IPv6 only WLAN which was using our DNS64 service. The iPad 
thought that the WLAN was broken because it only got an IPv6 address and 
no DHCPv4 response. It had time to send some packets using IPv6 through 
the NAT64 which created the mapping. Then it reset its WLAN and tried to 
associate with the same SSID again. Every time it created a new privacy 
extension based IPv6 address and a new mapping in the stateless NAT64 
device.

Within an hour, all the IPv4 addresses in the pool for our NAT64 were 
registered to this one device.

It would be my recommendation that there was either a Router 
Advertisement Flags Option for "do not use privacy extensions here" and 
that this was used in all setups that use DNS64 name servers, or that 
all such setups should use Managed Address Configuration aka DHCPv6 
address configuration.

-- 
	Aleksi Suhonen, Researcher
	Department of Communications Engineering
	Tampere University of Technology