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

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Jul 2012 11:36:27 -0500

Hi Alexsi,

On Tue, Jul 17, 2012 at 8:17 PM, Aleksi Suhonen <[email-masked]> wrote:
> 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:
>>
>>      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)
>
>
> Yes. Stateless NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1
>

Thanks for pointing this out.
But RFC 6144 is informational and what Section 3.2.1 describes is very
generic, it seems to describe kind of 4rd.

So you need to write a draft describing Stateless NAT64 :-), please.

Regards,

Behcet

---

From: Aleksi Suhonen <[email-masked]>
Date: Sun, 22 Jul 2012 04:27:49 +0300

Hi,

On 07/18/2012 07:36 PM, Behcet Sarikaya wrote:
> On Tue, Jul 17, 2012 at 8:17 PM, Aleksi Suhonen<[email-masked]>  wrote:

> So you need to write a draft describing Stateless NAT64 :-), please.

These people have been able to implement Stateless NAT64 with the 
existing drafts and RFCs:

http://www.litech.org/tayga/

And that is the implementation we are using. I think you should contact 
them about any issues regarding standards conformity.

Yours sincerely,

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 22 Jul 2012 05:32:37 +0000

> So you need to write a draft describing Stateless NAT64 :-), please.

Stateless IPv4/IPv6 translation is RFC 6145.

Are you poking at the fact that only RFC 6146 claims the name "NAT64"?

If so, I'll point out that nobody claims the name "NAT46", although draft-ietf-pcp-base-26.txt and draft-mdt-softwire-map-dhcp-option-03.txt attempt to refer to it.

Do the grep.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Jul 2012 13:28:23 -0500

On Sat, Jul 21, 2012 at 8:27 PM, Aleksi Suhonen <[email-masked]> wrote:
> These people have been able to implement Stateless NAT64 with the existing
> drafts and RFCs:
>
> And that is the implementation we are using. I think you should contact them
> about any issues regarding standards conformity.
>

Thanks for pointing this out. I am still puzzled, tayga is using DNS64
and they talk about NAT44.

Maybe you can explain their solution approach to me then I would be
happy to help document it :-)?

Regards,

Behcet

---

From: Philipp Kern <[email-masked]>
Date: Mon, 23 Jul 2012 20:34:13 +0200

Behcet,

> and they talk about NAT44.

tayga implements NAT64, not DNS64 (for instance bind9 could be used for the
latter). NAT44 is needed because the IPv6 source addresses are mapped into a
private IPv4 pool by default, which then needs masquerading (aka NAT44) into
the public internet. The site even says this:

| The dynamic pool can be chosen from private IPv4 address space
| (10.x.x.x, 192.168.x.x, etc) and can be of any size, although it needs
| to be large enough to contain one IPv4 address for every IPv6 host
| that needs to use the NAT64.

Of course you could also use public space without NAT44, but then you're
back to one public IPv4 address per client.

Kind regards
Philipp Kern

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 24 Jul 2012 17:00:29 -0500

On Tue, Jul 24, 2012 at 4:44 PM, Nathan Lutchansky <[email-masked]> wrote:
> On Sun, 22 Jul 2012, Aleksi Suhonen wrote:
>>
> TAYGA is an implementation of RFC 6145 with a small extension: if an
> incoming IPv6 packet has a source address that cannot be translated per RFC
> 6052, TAYGA can be configured to automatically bind that address for a time
> to a free IPv4 address from an administratively-configured pool.  In this
> configuration TAYGA is not truly stateless, but it still maintains no state
> regarding transport layer flows.
>
> Regarding Aleksi's experiences with privacy extensions depleting the entire
> dynamic pool, there is not much that can be done about this--it's just one
> more thing that RFC 4941 breaks.  I would love to have an RA option that
> forced privacy extensions to be disabled; I would use it on every network I
> maintain.  -Nathan

Hi Nathan,

I don't know the relationship of tayga and this presentation:

http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf

which is a stateless translator maintains the binding information of
*src.IPv6->src.IPv4 address*

It seems that this is what is called Stateless NAT64.

Reading the above
presentation, Stateless NAT64 solves the reverse problem of NAT64,
i.e. IPv4-only client
talking to IPv6-only server.

So as far as I am concerned the puzzle of Stateless NAT64 is solved.

Behcet

---

From: Aleksi Suhonen <[email-masked]>
Date: Wed, 25 Jul 2012 06:40:39 +0300

Hi,

> the public internet. The site even says this:

I would simplify the above like this:

Tayga implements Stateless NAT64, but it can be used to build a Stateful 
NAT64 setup by adding a NAT44 next to it.

---

From: Philipp Kern <[email-masked]>
Date: Wed, 25 Jul 2012 11:24:49 +0200

On Wed, Jul 25, 2012 at 06:40:39AM +0300, Aleksi Suhonen wrote:
> Tayga implements Stateless NAT64, but it can be used to build a
> Stateful NAT64 setup by adding a NAT44 next to it.

Except that it it stateful already with the default dynamic pool, but it can be
used statelessly.

Kind regards
Philipp Kern

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Jul 2012 10:58:06 -0500

On Tue, Jul 24, 2012 at 5:19 PM, Nathan Lutchansky <[email-masked]> wrote:
> On Tue, 24 Jul 2012, Behcet Sarikaya wrote:
>>
> Hi Behcet,
> Tore's presentation which you linked describes a stateless NAT64 scenario in
> which the IPv6 addresses of all of the IPv6 nodes which need to utilize the
> NAT64 translator are already known and can be statically bound to an IPv4
> address in the NAT64 configuration.
>
> The presentation does not address the scenario where the NAT64 translator is
> not pre-configured with a list of all the IPv6 addresses it will need to
> translate.  This would occur if a NAT64 translator could be utilized by any
> IPv6 node in a large network.  In this case, the translator must dynamically
> bind an available IPv4 address to each IPv6 node that attempts to use the
> translation service.  This is not behavior that is specified in RFC 6145,
> but it is implemented in TAYGA.
>
> Does that answer your question?  -Nathan

So tayga is a not so "stateless" form of so-called stateless NAT64.
I am amazed by the confusing terminology that is created around the
good old NAT64.

It would have been better to use a different name, like IVI.

Behcet

---

From: Tore Anderson <[email-masked]>
Date: Wed, 25 Jul 2012 18:58:37 +0200 (CEST)

Hello,

* Nathan Lutchansky

>> Tore's presentation which you linked describes a stateless NAT64
>> scenario in which the IPv6 addresses of all of the IPv6 nodes
>> which need to utilize the NAT64 translator are already known and
>> can be statically bound to an IPv4 address in the NAT64
>> configuration.
>> 
>> The presentation does not address the scenario where the NAT64
>> translator is not pre-configured with a list of all the IPv6
>> addresses it will need to translate.

Actually, only a single slide (22) in the deck discusses a situation
where a list of explicit translations are configured on the
translator(s). This behaviour is not specified in RFC 6052, but I
believe it would be very useful feature for my use case.

The rest of the presentation is all about pure RFC 6052+6145
operation. The address mapping algorithm in RFC 6052 does not require
the individual IPv6 addresses to be configured, the only thing you
need to configure is the prefixes you'll be using for translation.

An example of a complete configuration is found in appendix B in the
slide deck. I ran it in production for several months, worked great.

>> In this case, the translator must dynamically bind an available
>> IPv4 address to each IPv6 node that attempts to use the
>> translation service.  This is not behavior that is specified in
>> RFC 6145, but it is implemented in TAYGA.

That sounds very much like a stateful approach to me, the word
"dynamically" is a dead giveaway...

* Behcet Sarikaya

> It would have been better to use a different name, like IVI.

Heh. «IVI» is no better. I've looked, and I can find no official
definition of the term. RFC 6219 refers to it, but what «IVI» actually
is the name of, as far as I can tell, is a long-defunct Linux
implementation of RFC 6052+6145 found at www.ivi2.org. Similarly,
«Stateless NAT64» isn't a official standard either, as the only
mention of «NAT64» is in RFC 6146 - that only defines «Stateful NAT64».

The most correct name that I've found for the technology (as opposed
to individual implementations) is «SIIT», which is defined in RFC 6145.

Tore

---

From: Ray Hunter <[email-masked]>
Date: Fri, 27 Jul 2012 08:46:43 +0200

IMHO This may have niche application in managed environments, but anyone 
who is thinking about deploying *anything* stateful on an IPv6 Internet 
facing data centre (Section 4 of the draft) needs first to read a health 
warning in bold about potential resource depletion. For translation: 128 
bits of address information does not fit in 32 bits. End of story. And I 
still don't know of any machine yet built that can fully track state for 
128 bits of addressing e.g. to prevent the DoS attack before it reaches 
the translation pool. We may have solved address depletion, but we've 
now shifted the bottleneck to memory depletion. I therefore don't think 
the v6ops wg should be encouraging such risky behaviour as suggested in 
the draft. Instead, we should be recommending use of end to end native 
IPv6 when connecting to the IPv6 Internet, and putting strategies in 
place to ensure individual machines' resources aren't overwhelmed e.g. 
http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance-02.

regards,
RayH

Behcet Sarikaya wrote:
> On Tue, Jul 24, 2012 at 4:44 PM, Nathan Lutchansky<[email-masked]>  wrote:

---

From: GangChen <[email-masked]>
Date: Fri, 27 Jul 2012 19:04:12 +0800

2012/7/27, Ray Hunter <[email-masked]>:
> bits of address information does not fit in 32 bits. End of story.

Exactly. The draft asserted the same concern regarding the address depletion

>And I

I have to apologize if the draft gives you impression that is
suggested. We documented that because we are experiencing several
cases in which the usage is adopted nowadays. The draft intended to
identify the issues and raise a caution, i.e. those off-the-shelf
solutions should be constrained to small-scale. FWIW, the draft (which
we would post soon) would describe the expense further after chair's
kind reviews. Clear statement should be "For operators who already
deployed such mode, it should be cautious and aware the problems it
may cause.
Such usages should be restrained to a relative small-scale, since
native IPv6 is always desirable. For operators who seek a clear
precedent for operating reliable ipv6-only services, it's not recommended,
because the usages is problematic at several aspects."

Best Regards

Gang

>>>> existing
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>