Hello Aleksi, Please see my reply inline.
2012/7/22, Aleksi Suhonen <[email protected]>: > 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 > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
