RE: on NAT-PT

[<juha.wiljakka@nokia.com>]

Hi, Margaret!

Some comments below (marked with 'JW'):

-----Original Message-----
From: ext Margaret Wasserman [mailto:mrw@windriver.com]
Sent: 02 December, 2002 14:27

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

JW: A general comment: I am still not sure that everything can be done with dual stack (with or without IPv4 NAT), there can be cases in which you cannot avoid protocol translation...

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.

JW: Yes, I think that introduction of new IPv6-only networks (native IPv6 from the beginning, and possibly needing connections with legacy IPv4 nodes) is a good example.

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:

JW: Yes, IMS part of the 3GPP Release 5 network is IPv6-only (as discussed several times also on this mailing list). It is a good question, how probable the case that a Rel5 IMS UE needs to connect to an IPv4 node (outside the IMS domain) is, but for the sake of completeness that case needs to be documented in 3GPP scenarios & analysis.

In the 3G case, it seems likely that the NA(P)T-PT functionality would
co-reside with the GGSN function.  

JW: Hmm... I would not assume that NAT-PT and GGSN are co-located. NAT-PT could be located on the edge of the operator's network and the Internet. Or in the IMS case (IMS scenario 1), NAT-PT would be located on the edge of the IMS domain and the IPv4 network (public Internet). GGSN can anyway have several Access Points (both IPv4 and IPv6) to have connections to different networks (one IPv6 Access Point can support IPv6 IMS connections, second one can support connections to public IPv6 internet, and third one can support connections to IPv4 Internet, etc.).

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.

JW: As I tried to explain above, I don't keep this kind of 'limited model' very probable.

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.

JW: I would still keep making *IPv6* connection from phone to phone a better idea... That's the real peer-to-peer networking :-)

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

JW: As a general comment, IPv6 NAT-PT failure modes / problems compared to IPv4 NAT problems should be documented (if not done already by someone).

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.  

JW: This sounds like a valid assumption for many operators. But we have to still remember that there is one part of the network that is IPv6-only and that is the Rel5 IMS.

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?

JW: I still think that we need something like NAT-PT for some special cases, although the majority of the transition cases can be solved using dual stack & tunneling. I would suggest well documenting the NAT-PT problems and see what can be done / fixed.

Thanks,
	 -Juha-