Re: draft-chen-v6ops-nat64-experience-02

GangChen <phdgang@gmail.com> Sun, 22 July 2012 04:27 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 9F5D921F847E; Sat, 21 Jul 2012 21:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.995
X-Spam-Level:
X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.004, 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 1qqpBaQM1ura; Sat, 21 Jul 2012 21:27:25 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C94E821F847C; Sat, 21 Jul 2012 21:27:24 -0700 (PDT)
Received: by obbwc20 with SMTP id wc20so8538824obb.31 for <multiple recipients>; Sat, 21 Jul 2012 21:28:25 -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=g3mhZ2oC+4iWkm8IdMBZ4L6N3Oa/GZLPgnK4GH0yXN8=; b=xse5fmhsUhASusxjLFwNZ2Ps5O5bgjDLqtyeosVB6kNK/XRilGOWYTrB2dfDeGPflw 7foHeLSVWdJRxZD3AylXqsZynWlB2RcQQ29HPZS0yR/pdHvp53KvPJCAP0FGHdxQIizE fpm0QOjEpZHzvsk4n/yV4ixt1Db4YbmKZfm3n9T/3yx1aRJr80dqDroQu1M92Tns54ps CdJEZ1RcMhx/GV3pnFOVzrxXhRA9wB0xeMb6sS3bV5RRg/olhtX7NxsRMIBGk598TdFc xymB5GARE99Y3/O7HF1wuhmnxrWWrn4iUpiCqEbTDwwe4VrzA0pkF+pmIWwtMoK45yE0 n29g==
MIME-Version: 1.0
Received: by 10.50.173.5 with SMTP id bg5mr7633384igc.35.1342931304837; Sat, 21 Jul 2012 21:28:24 -0700 (PDT)
Received: by 10.42.151.194 with HTTP; Sat, 21 Jul 2012 21:28:24 -0700 (PDT)
In-Reply-To: <500B5A2D.6000408@tut.fi>
References: <4FF696AA.3050508@tut.fi> <CAM+vMER0zBfS85QHEuhS1eS_3FZDwXSKdhaFHnEgvecAFiYZ8A@mail.gmail.com> <500B5A2D.6000408@tut.fi>
Date: Sun, 22 Jul 2012 12:28:24 +0800
Message-ID: <CAM+vMER99GCOuFi_tS=7OxawecEz+sHx-10J=kdzta4o3OeNoA@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" <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: Sun, 22 Jul 2012 04:27:25 -0000

Hello Aleksi,

Please see my reply inline.

2012/7/22, Aleksi Suhonen <Aleksi.Suhonen@tut.fi>fi>:
> Hi,
>
> On 07/18/2012 12:05 PM, GangChen wrote:
>> cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience
>
> Oh sorry. I thought I started the discussion on the right mailing-list
> in the first place, but turns out it was wrong.
>
>> =>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.
>
> I think you're confused by the name "Stateless NAT64" because it's not
> stateless despite its name. Stateless NAT64 maintains state about the
> src.IPv6->src.IPv4 address mappings, while Stateful NAPT64 maintains
> state about both addresses and ports.

I have same understanding on the term of  "Stateless NAT64" with
http://www.ietf.org/mail-archive/web/ipv6/current/msg16070.html

> Take a minute to think about it: Stateless NAT64 creates a 1:1 mapping
> between its IPv6 clients and the IPv4 pool it's been given. If it did
> not maintain a mapping, how would returning IPv4 packets be mapped back
> to IPv6? Where would it find which IPv6 address should be the final
> destination?

Please take a look at Page13~22 at
http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf

If a stateless translator maintains the binding information of
*src.IPv6->src.IPv4 address*, the essential feature of "Does not
require flows to flow bidirectionally across a single translator"
would lose.

Therefore, I prefer to understand your above description is a variant
of RFC6146, i.e. in the case of BIB/STE excluding port information.

BRs

Gang


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