Subject: Re: on NAT-PT

From: Alain Durand <[email-masked]>
Date: Sun, 01 Dec 2002 21:47:03 -0800

On Thursday, November 28, 2002, at 01:16 AM, Brian E Carpenter wrote:

> I think we need an RFC which discusses the issues with NAT-PT
> that are discussed for NAT-v4 in RFC 2993 and RFC 3027.
> Maybe it could be quite short, if the issues are the same,
> but it needs to be written.

As NAT-PT stand, in the v6 to v4 translation, it is worse than
regular NAT, because of side effects introduce by the DNS ALG part.

In the v4 to v6 translation, it is problematic because
of the possibility for DOS attack.

As described, NAT-PT does not scale as regular NAT, this is bad,
especially when people (like 3G) have been discussing using it
massively! (I'm not saying  it is a good thing to use NAT massively,
and although the current RFC tries to somehow limit its domain
of use, the statements are not strong enough and side effects need to be
documented)

NAT-PT needs to be revisited:
It needs to remove the DNS-ALG part in the v6 tov4 case,
it needs to limit the DOS thread and need to scale better,
at least as well/bad as NAT.
A new RFC needs to define the tradeoff when to use it
compare to using dual stack.

	- Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 02 Dec 2002 07:27:05 -0500

Hi Alain,

>at least as well/bad as NAT.

Apparently, there is some disagreement about whether the DNS ALG part needs
to be modified.  Could you provide more details about why you think it needs
to change?

>compare to using dual stack.

When would it make sense to use NAT-PT instead of dual-stack (with or
without IPv4 NAT)?  I would argue that there NO current or immediate,
realistic cases where NA(P)T-PT is a better technical solution, for
several reasons:

         (1) Dual stack should represent very little increase in code
                 size or system requirements over an IPv6 stack for
                 a host.  Does anyone even have an implementation that
                 can be built (not just configured, but compiled and
                 loaded) to be IPv6-only at this point?
         (2) IPv4 NAT implementations are already widely deployed,
                 mature and reliable.  Also, the ALGs have all been
                 developed and widely deployed, and the problems
                 caused by IPv4 NAT for each application are well-
                 understood, and applications have adapted, as needed.
         (3) The dual stack/IPv4 NAT approach allows two hosts behind
                 the same NAT box to establish an IPv4 connection
                 (if they can find each other), while NA(P)T-PT does
                 not (they don't even have IPv4 addresses).

The only argument I have heard for why one would use NAT-PT is in a large,
brand new network, where it might be cheaper/easier to deploy an IPv6-only
infrastructure, compared with deploying a dual stack infrastructure.

The extra costs of a dual-stack/IPv4 NAT deployment, over an IPv6-only
deployment include:

         (1) Providing IPv4 configuration to the routers.  You already
                 need to touch each router to configure IPv6, so this
                 is just a matter of entering a few more pieces of
                 information while you are there.
         (2) Deploying DHCPv4 servers.  (This isn't required in
                 a 3G network, as IPv4 address allocation is don't
                 automatically for IPv4 PDP contexts, but pools of
                 (possibly private) IPv4 addresses would need to
                 be provided to the GGSNs.
         (3) Managing, monitoring & maintianing the IPv4 network (in
                 addition to the IPv6 network that uses the same lines
                 and hardware).  I can't estimate what this costs, but
                 since they share the same lines and hardware, adding IPv4
                 shouldn't increase the number of truck rolls.

The primary example that people give of a major new network that would
be IPv6-only is the 3G case...  This is quite a theoretical case at this
point, but let's use it as an example:

In the 3G case, it seems likely that the NA(P)T-PT functionality would
co-reside with the GGSN function.  In this environment, you could
_only_ support IPv6-only phones (there is no v4 infrastructure behind
the NAT-PT/GGSN line).  And, those phones could _only_ speak IPv4 to
hosts on the other side of the NAT-PT/GGSN border, right?  I'm not
sure why anyone thinks that this would be acceptable, given the huge
number of IPv4-only applications that exist today.

If we are going to recommend this as a solution (which I don't think
we should), I think that we need to be very clear about some things:

         (1) Two phones behind the same GGSN/NAT-PT could not make
                 an IPv4 connection to each other, but two phones
                 behind different GGSN/NAT-PTs could (with a third
                 party rendezvous point or a STUN-like mechanism).
                 So, be ready to answer the question:  "Why did my
                 favourite application (i.e a game) work fine when
                 my husband was in Poughkeepsie, but it doesn't work
                 now that he's home?".  What's the answer?  "Ma'am,
                 just have your husband drive 4 miles across town
                 and turn his cell phone off and back on again there.
                 Then, as long as he doesn't turn it off again, your
                 application should work?"  Yeah, right.

         (2) IPv6 NAT-PT will have different application failure
                 modes than IPv4 NAT, so be ready to answer the
                 question:  "Why does my laptop application work
                 fine when I'm connected at home or work, but doesn't
                 work when I am connected through my 3G cell phone?"
                 Honest answer (which will never be given):  "That's
                 because we chose unproven and poorly understood
                 technology to support IPv4 address sharing, rather
                 than relying on the technology that has been widely
                 deployed for years."

I also think it is extremely doubtful that operators (in the next N years,
anyway, where N > 5) will want to deploy an IPv6-only 3G network.  I've
worked with a number of vendors of 3G hardware, and none of them seem
to be building devices that assume that the phones will all be IPv6-only
(and capable of only establishing IPv6 PDP contexts).  I am well
acquainted with the design and requirements of one major vendor's
GGSN, and their performance requirements indicate that they expect to
service a large number of IPv4 connections (IPv4 PDP contexts), from
IPv4-only and/or dual-stack phones, as well as a large number of IPv6
connections.

So, I think that we should issue a strong recommendation against using NAT-PT
in any environment and move it to historical?

If, in the fullness of time, it turns out that we have a mostly-IPv6
Internet and a real-life need arises to support legacy IPv4-only equipment
in an IPv6 world, we can take out NAT-PT, dust it off, and see if it will
be helpful in that situation.

Margaret

---

From: [email-masked]
Date: Mon, 02 Dec 2002 23:24:49 +0900

haven't you checked two of my messages started this thread?

>It needs to remove the DNS-ALG part in the v6 tov4 case,

	if you could do it without changing IPv6-only clients, i'm fine with
	that.

>at least as well/bad as NAT.

	what kind of DoS?

	what kind of scalability differences do you see between v4-v4 NAT and
	v6-v4 NAT-PT?  i don't see any (except that NAT-PT might potentially
	need to support massive number of customers, depending on
	configuration - you can balance the load between NAT-PT translation
	boxes so it's no issue).

>compare to using dual stack.

itojun