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

From: Aleksi Suhonen <[email-masked]>
Date: Fri, 06 Jul 2012 10:41:30 +0300

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:

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.

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.

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Jul 2012 10:59:25 -0400

>>>>> "Aleksi" == Aleksi Suhonen <[email-masked]> writes:
    Aleksi> Within an hour, all the IPv4 addresses in the pool for our
    Aleksi> NAT64 were registered to this one device.

Do I understand that you attempt to provide a single IPv4 address 1:1
with a an internal IPv6 address? (NAT vs NAPT)

Can you tell me what your expiry time is for reclaiming the IPv4 address?
Would IPv6 ping'ing the internal device help?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Simon Perreault <[email-masked]>
Date: Sat, 07 Jul 2012 14:28:52 -0700

> all such setups should use Managed Address Configuration aka DHCPv6

...only when your NAT64 is configured to provide 1:1 mapping between 
IPv4 and IPv6 addresses. Privacy extensions have been working fine for 
us with n:1 mapping.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Jul 2012 12:18:12 -0500

> with a an internal IPv6 address? (NAT vs NAPT)

It seems like this is what is called stateless NAT64.
I am not sure if there is any document specifying stateless NAT64?

Regards,

Behcet

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 9 Jul 2012 10:38:35 -0700

> I am not sure if there is any document specifying stateless NAT64?

Stateless = http://tools.ietf.org/html/rfc6145

Stateful = http://tools.ietf.org/html/rfc6146

If the goal is providing a dynamic access from an IPv6-only network
toward IPv4-only internet, RFC 6146 is the optimal choice.

RFC 6145 has limited use for the cases for IPv6 - > IPv4 since it is
1:1 mapping.  Most people do IPv6 because IPv4 is limited, so ...
doing 1:1 mapping does not really buy you anything.  You can just use
IPv4 and achieve the same scale.

The best use case i have seen for RFC 6145 is for the data center
environment http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf
 as well as the mapping of the entire IPv4 internet into IPv6 as is
the case of 464XLAT CLAT in the IPv4->IPv6  scenario.

CB

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Jul 2012 13:41:44 -0500

> Stateless = http://tools.ietf.org/html/rfc6145

Are you sure?

Here is a quote from 6146:
Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4
   packets and vice versa.  The translation is done by translating the
   packet headers according to the IP/ICMP Translation Algorithm defined
   in [RFC6145].

Regards,

Behcet

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Jul 2012 14:49:46 -0400

On 2012-07-09 14:41, Behcet Sarikaya wrote:
> On Mon, Jul 9, 2012 at 12:38 PM, Cameron Byrne<[email-masked]>  wrote:
>> On Mon, Jul 9, 2012 at 10:18 AM, Behcet Sarikaya<[email-masked]>  wrote:

Cameron is right. RFC6145 is often referred to as "stateless NAT64".

Simon

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Jul 2012 14:48:17 -0500

> Cameron is right. RFC6145 is often referred to as "stateless NAT64".
That means stateless NAT64 is not defined maybe it is a myth.

Regards,

Behcet

---

From: Aleksi Suhonen <[email-masked]>
Date: Wed, 18 Jul 2012 04:17:39 +0300

Hi,

Sorry for late response. It's the summer holiday season here. O:-)

On 07/06/2012 05:59 PM, Michael Richardson wrote:
>
>>>>>> "Aleksi" == Aleksi Suhonen<[email-masked]>  writes:

Yes. Stateless NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1

> Can you tell me what your expiry time is for reclaiming the IPv4 address?

2 hours. However, anything above 5 minutes will yield the same result on 
today's Internet. And 5 minutes is too short.

> Would IPv6 ping'ing the internal device help?

Hmm? Help with what? I'm not sure I understand you.

---

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

> for over a year now and I'd like to submit the following experience for

Your inputs are welcome.

> 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.

> all such setups should use Managed Address Configuration aka DHCPv6

Those potential solutions are worth to be discussed further.
Especially, new added RA flags option would require additional
specification efforts.

Many thanks

Gang

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jul 2012 10:26:27 -0400

>>>>> "Aleksi" == Aleksi Suhonen <[email-masked]> writes:
    Aleksi> Sorry for late response. It's the summer holiday season
    Aleksi> here. O:-)

    >> Do I understand that you attempt to provide a single IPv4 address
    >> 1:1 with a an internal IPv6 address? (NAT vs NAPT)

    Aleksi> Yes. Stateless
    Aleksi> NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1

okay, so every v6 device gets 1 IPv4.
I think that few people have enough IPv4 to do this, and your research
demonstrates the problems with trying to do that.  I think that most
will do stateful NAPT64.

    >> Can you tell me what your expiry time is for reclaiming the IPv4

    Aleksi> 2 hours. However, anything above 5 minutes will yield the
    Aleksi> same result on today's Internet. And 5 minutes is too short.

    >> Would IPv6 ping'ing the internal device help?

    Aleksi> Hmm? Help with what? I'm not sure I understand you.

Would it help to expire the lease faster if you did a liveness check on
the IPv6 device.

---

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