RE: 3gpp-analysis-05: Use of NAT-PT in IPv6 UE -> IPv4 node

[<juha.wiljakka@nokia.com>]

Hi!

Comments below (JW):

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 19 September, 2003 09:10

<chair hat=on>
We hope to be able to WG LC and finish the document very soon.  Hopefully
the WG LC could be initiated after the next revision, before Minneapolis.
But we'll see how it turns out.
<chair hat=off>

 JW: Yep, let's see; that would be a good schedule.

First, a couple of points of discussion:

 - If UE is IPv6-only, and you hook up an IPv4 (or dual-stack) laptop to 
the UE, would you be able to use IPv4 through the UE (using separate PDP 
context)?
 - Is there something why this would be undesirable (double billing with 
two PDP contexts?)

 JW: Hmm...that depends on the fact whether IPv4 dial-up is supported
in the UE, i.e. that means PPP(v4) support and it must be possible to
set up a PDP context for PC dial-up... If we strictly talk about IPv6-
only UE, maybe that is not possible, but it depends on the implementation.

What I'm trying to grasp at is this: if someone deploys IPv6-only UE's,
for specific purposes only (e.g. making calls, browsing the web), can we
expect that the user of the device does not require geneirc purpose
Internet connectivity (e.g. being able to connect to IPv4 address X, 
protocol Y, port Z)?

 JW: Well...it seems that some level of IPv4 connectivity will be needed for 
quite a long time (even though I personally hope that the transition 
to IPv6 would happen more rapidly). Anyway, making prognoses is always
difficult.  

substantial
-----------

The issues I'm still not very confortable with:

1) NAT-PT use and the recommendations.   I don't think it's good practice to
deploy IPv6-only UE's before there are no longer services which cannot be
proxied or otherwise translated one by one.  There are significant amount of
dangers associated with general-purpose translation, and NAT-PT is not
likely to diminish those.

What I'd would like to see in the document:
 - rather strong recommendation to avoid deploying IPv6-only UE's until the
usage (and IPv6) environments have evolved so that generic translation is no
longer needed, and

 JW: I think that a general recommendation for dual stack UEs in the
near future is a rational one. At least that seems to be the natural 
step after IPv4-only UEs. But we should also encourage manufacturers 
to make dual stack UEs instead of v4-only UEs! :-)

 - subsequently, greatly reducing the amount of text wrt NAT-PT.

The former should/could include like:
 * reasoning why IPv6-only deployments are/are not valid (this really 
seems to depend a lot on how specific purpose devices those can be assumed 
to be) 
 * recommendation to avoid IPv6-only deployments until such time that 
generic translation is no longer needed
 * some description why "specific translation" (or proxying) is more 
desirable than overall translation

The latter should/could be reduced become the NAT-PT applicability team is 
already struggling with this effort (there will be a draft soon).

Below is the text I wrote which would seem to be better for now 
(presupposes that NAT-PT applicability would shun NAT-PT, obviously..).

=====
-- in short, I've edited the 3.4 section extensively from scratch, moved 
the bulk of previous 3.4 section to appendix A with some rewording here 
and there (until it's known how to deal with it) --

 3.4 IPv6 UE Connecting to an IPv4 Node 

The deployment of generic-purpose IPv6(-only) UEs is not recommended until
the IPv6 deployment has become so prevalent that direct communication with
IPv4(-only) nodes will no longer be necessary.

Specific-purpose UEs, capable of doing only specific kinds of tasks, are a
slightly different thing: it may be possible to make assumptions on the
nodes and communication protocols they need to use. Then it may be
possible to deploy specialized IPv6(-only) equipment because it's known
that they do not need to reach an IPv4(-only) nodes except using very
specific applications and methods -- and in that case, it is possible to
use specific translation and proxying techniques, not generic
translation.

Thus there are three main ways for IPv6(-only) nodes to communicate with
IPv4(-only) nodes (excluding avoiding such communication in the first 
place):

 1) the use of generic-purpose translator (e.g. NAT-PT [2766]) in the 
local network (not recommended),

 2) the use of specific-purpose protocol relays (e.g., IPv6<->IPv4 
TCP relay configured for a couple of ports only [TRT]) or application 
proxies (e.g., HTTP proxy, SMTP relay) in the local network, or

 JW: How much do we have real life / implementation experience on TRT?

 3) the use of specific-purpose mechanisms (as described above in 2) in 
the foreign network; these are indistinguishable from the IPv6-enabled 
services from the IPv6 UE's perspective, and is not discussed further 
here.

The use of generic-purpose translators (such as NAT-PT) is not recommended 
[NATPTappl]; appendix A lists some 3GPP-specific issues related to the use 
of translators.

 JW: In my opinion, NATPTappl will have an important task explaining why you 
don't want to encourage people using NAT-PT as a generic
transition mechanism. I haven't fully understood the big picture. With dual
stack (and IPv4) we usually have to use v4-NATs anyway. Just a question: if I say
that the evilness of NA(P)T is X, how evil would you then say NA(P)T-PT is (compared
to X)?

For many applications, application proxies can be appropriate (e.g. HTTP
proxies, SMTP relays, etc.). Such application proxies will not be
transparent to the UE. Hence, a flexible mechanism with minimal manual
intervention should be used to configure these proxies on IPv6 UEs. Within
the 3GPP architecture, application proxies can be placed on the GGSN
external interface (Gi), or inside the service network; see section 5 for 
more about UE configuration mechanisms.


Section 4.1 [reword the last sentence to:]

   The problems related to NAT-PT are documented in appendix A.

Normative References
   [Add TRT (the TCP/UDP relay RFC)]

Appendix A - On the Use of Generic Translators in the 3GPP Networks

    This appendix lists mainly 3GPP-specific arguments about generic 
    translators, even though the use of generic translators is 
    discouraged.  The section may be removed in future versions of the 
    memo.

    Due to the significant lack of IPv4 addresses in some domains, port
    multiplexing is likely to be a necessary feature for translators
    (i.e. NAPT-PT). If NA(P)T-PT is used, it needs to be placed on the
    GGSN external (Gi) interface, typically separate from the GGSN.
    NA(P)T-PT can be installed, for example, on the edge of the
    operator's network and the public Internet. NA(P)T-PT will
    intercept DNS requests and other applications that include IP
    addresses in their payloads, translate the IP header (and payload
    for some applications if necessary) and forward packets through its
    IPv4 interface.

    NA(P)T-PT introduces limitations that are expected to be magnified
    within the 3GPP architecture. Some of these limitations are listed
    below (notice that some of them are also relevant for IPv4 NAT). We
    note here that [v4v6trans] analyzes the issues when translating
    between IPv4 and IPv6.

       1. NA(P)T-PT is a single point of failure for all ongoing
         connections.

       2. There are additional forwarding delays due to further
         processing, when compared to normal IP forwarding.

       3. There are problems with source address selection due to the
         inclusion of a DNS ALG on the same node [NATPT-DNS].

       4. NA(P)T-PT does not work (without application level gateways)
         for applications that embed  IP addresses in their payload.

       5. NA(P)T-PT breaks DNSSEC.

       6. NA(P)T-PT does not scale very well in large networks.

    3GPP networks are expected to handle a very large number of
    subscribers on a single GGSN (default router). Each GGSN is
    expected to handle hundreds of thousands of connections.
    Furthermore, high reliability is expected for 3GPP networks.
    Consequently, a single point of failure on the GGSN external
    interface would raise concerns on the overall network reliability.
    In addition, IPv6 users are expected to use delay-sensitive
    applications provided by IMS. Hence, there is a need to minimize
    forwarding delays within the IP backbone. Furthermore, due to the
    unprecedented number of connections handled by the default routers
    (GGSN) in 3GPP networks, a network design that forces traffic to go
    through a single node at the edge of the network (typical NA(P)T-PT
    configuration) is not likely to scale. Translation mechanisms
    should allow for multiple translators, for load sharing and
    redundancy purposes.

    To minimize the problems associated with NA(P)T-PT, the following
    actions may be needed:

         1. Separate the DNS ALG from the NA(P)T-PT node (in the "IPv6
            to IPv4" case).

         2. Ensure (if possible) that NA(P)T-PT does not become a
            single point of failure.

         3. Allow for load sharing between different translators. That
            is, it should be possible for different connections to go
            through different translators. Note that load sharing alone
            does not prevent NA(P)T-PT from becoming a single point of
            failure.

 JW: The idea of having this text in an Appendix is ok for me.


BR,
	-Juha-