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

GangChen <> Sun, 22 July 2012 04:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F5D921F847E; Sat, 21 Jul 2012 21:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.995
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1qqpBaQM1ura; Sat, 21 Jul 2012 21:27:25 -0700 (PDT)
Received: from ( []) by (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;; 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 with SMTP id bg5mr7633384igc.35.1342931304837; Sat, 21 Jul 2012 21:28:24 -0700 (PDT)
Received: by with HTTP; Sat, 21 Jul 2012 21:28:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sun, 22 Jul 2012 12:28:24 +0800
Message-ID: <>
Subject: Re: draft-chen-v6ops-nat64-experience-02
From: GangChen <>
To: Aleksi Suhonen <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: v6ops <>, "" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>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

> 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

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.



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