Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02

From: GangChen <[email-masked]>
Date: Wed, 18 Jul 2012 17:05:15 +0800

cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience

2012/7/6, Aleksi Suhonen <[email-masked]>:
> 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
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: GangChen <[email-masked]>
Date: Sun, 22 Jul 2012 12:28:24 +0800

Hello Aleksi,

Please see my reply inline.

2012/7/22, Aleksi Suhonen <[email-masked]>:
> Hi,
>
> On 07/18/2012 12:05 PM, GangChen wrote:
> Oh sorry. I thought I started the discussion on the right mailing-list
> in the first place, but turns out it was wrong.
>
> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Jul 2012 14:29:53 -0500

> require flows to flow bidirectionally across a single translator"

Exactly.

I now understood what is meant by Stateless NAT64 reading the above
presentation. It solves the reverse problem of IPv4-only client
talking to IPv6-only server.

Regards,

Behcet