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

[GangChen <[e-mail]>]

Hello Aleksi,

Please see my reply inline.

2012/7/22, Aleksi Suhonen <[e-mail]>:
> 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
>