Re: on NAT-PT

[Margaret Wasserman <mrw@windriver.com>]

Hi Alain,

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

> A new RFC needs to define the tradeoff when to use it
> 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