Re: draft-chen-v6ops-nat64-experience-02
GangChen <phdgang@gmail.com> Wed, 18 July 2012 09:04 UTC
Return-Path: <phdgang@gmail.com>
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 9418E21F86EA; Wed, 18 Jul 2012 02:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 54QaJlbd0UFG; Wed, 18 Jul 2012 02:04:25 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0F7721F86D5; Wed, 18 Jul 2012 02:04:25 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so1018946vcb.31 for <multiple recipients>; Wed, 18 Jul 2012 02:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U2HpjSggEpu73XsQ8365wAPDIRb3bc2BKhJMjz5IcPA=; b=Zzpfq2egKW4Q2i/Mq20ykgorH0kZG/8N1GFF4XJLJ2X2tprEIvWWlD/eCp6sue9YFG fDi9gEmZ3lDVBKLOMCTlGMgw2bNJMJGDmSCwMpunuAnrz76IOml/O9qPcGBlRquX+Dog RgOCkcsbgngf9XYJra5wiO/uogwavV592LyoAZxAqywq97PT2djVbdhVVLK0H53fOZxu leAuPbREBOcplVNyCHsEszXYzSxzYX0UIYYvj+hsLA8eTiXV0pUhAFErbjCLD8t2Qlyh /4eXJsXV/41Bacsnzthn4Lidyi96vRXVMAATQyc37ie6T4+VmiQ28NWEr0wr+O05DvhC 1EmQ==
MIME-Version: 1.0
Received: by 10.52.100.4 with SMTP id eu4mr43127vdb.66.1342602315106; Wed, 18 Jul 2012 02:05:15 -0700 (PDT)
Received: by 10.58.58.36 with HTTP; Wed, 18 Jul 2012 02:05:15 -0700 (PDT)
In-Reply-To: <4FF696AA.3050508@tut.fi>
References: <4FF696AA.3050508@tut.fi>
Date: Wed, 18 Jul 2012 17:05:15 +0800
Message-ID: <CAM+vMER0zBfS85QHEuhS1eS_3FZDwXSKdhaFHnEgvecAFiYZ8A@mail.gmail.com>
Subject: Re: draft-chen-v6ops-nat64-experience-02
From: GangChen <phdgang@gmail.com>
To: Aleksi Suhonen <Aleksi.Suhonen@tut.fi>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: v6ops <v6ops@ietf.org>, 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: Wed, 18 Jul 2012 09:04:26 -0000
cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience 2012/7/6, Aleksi Suhonen <Aleksi.Suhonen@tut.fi>: > 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: Your inputs are welcome. > 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. =>I may hardly understand that is a problem with stateless NAT64. RFC6145 doesn't require creating a mapping state because it's *stateless*. The package forwarding is based on mapping rules, which is nothing to do with *lifetime*. Therefore, above statement of IPv4 pool exhaustion may not apply to stateless NAT64. I suspect this problem may occur in a stateful NAT64 context. The frequent reclaiming behavior would consume unnecessary resource by creating overwhelming states on NAT64 box. Your further check is expected. > 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. Those potential solutions are worth to be discussed further. Especially, new added RA flags option would require additional specification efforts. Many thanks Gang > -- > Aleksi Suhonen, Researcher > Department of Communications Engineering > Tampere University of Technology > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
- draft-chen-v6ops-nat64-experience-02 Aleksi Suhonen
- Re: draft-chen-v6ops-nat64-experience-02 Michael Richardson
- Re: draft-chen-v6ops-nat64-experience-02 Simon Perreault
- Re: draft-chen-v6ops-nat64-experience-02 Behcet Sarikaya
- Re: draft-chen-v6ops-nat64-experience-02 Cameron Byrne
- Re: draft-chen-v6ops-nat64-experience-02 Behcet Sarikaya
- Re: draft-chen-v6ops-nat64-experience-02 Simon Perreault
- Re: draft-chen-v6ops-nat64-experience-02 Behcet Sarikaya
- Re: draft-chen-v6ops-nat64-experience-02 Aleksi Suhonen
- Re: draft-chen-v6ops-nat64-experience-02 GangChen
- Re: draft-chen-v6ops-nat64-experience-02 Michael Richardson
- Re: draft-chen-v6ops-nat64-experience-02 GangChen
- Re: draft-chen-v6ops-nat64-experience-02 Behcet Sarikaya