Subject: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jul 2003 10:30:52 +0300 (EEST)

Hi,

This is my second issue in the 3GPP analysis document.

----

Section 3.4 (see the text below), "IPv6 UE Connecting to an IPv4 Node",
describes the common case of IPv6-only UE connecting to an IPv4 node.  
The technique specified is NAT-PT, and the text includes some words of
NAT-PT applicability as well as a reference to NAT64.

I believe this approach is not a good one, as here NAT-PT (or something 
like that) is used as a general purpose translation device for all kinds 
of traffic.

I think we need to figure out whether this is really necessary or 
acceptable.

My personal belief is that we consider the model:
 - Use IPv4 where appropriate, 
 - Not deploy IPv6-only UE's if they have a need to reach IPv4 services, and
 - Use application proxies (such as HTTP gateways, maybe even TCP/UDP 
relays specific to an application) where appropriate to make it easier to 
go for IPv6-only UE's at some point if it's the way to go.

Other thoughts?

---- cut -----
 3.4 IPv6 UE Connecting to an IPv4 Node
                                                                                                       
    IPv6 nodes can communicate with IPv4 hosts by making use of a
    translator (SIIT [RFC2765], NAT-PT [RFC2766]) within the local
    network. For some applications, application proxies can be
    appropriate (e.g. HTTP, email relays, etc.). Such applications 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.

    However, since it is difficult to anticipate all possible
    applications, there is a need for translators that can translate
    headers independent of the type of application being used.
                                                                                                       
    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).
                                                                                                       
    When 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. However, the NAT-PT issues should be clearly
    documented in an RFC in the v6ops Working Group and a decision
    should be made, whether revisiting the NAT-PT RFC is necessary /
    what kind of update is needed.

       1. NA(P)T-PT is a single point of failure for all ongoing
         connections.
                                                                                                       
       2. Additional forwarding delays due to further processing, when
         compared to normal IP forwarding.
                                                                                                       
       3. 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 can be recommended:
                                                                                                       
         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.

    There are some ways to fix the problems with NA(P)T-PT, one
    suggestion is [NAT64].
                                                                                                       
    When thinking the DNS issues, the IPv6 UE needs to find the IPv4
    address in the DNS [DNStrans]. Note that DNSSEC is broken if
    NA(P)T-PT is used.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 22 Jul 2003 06:37:26 -0400

> 
 > The text in elmalki draft seems to suggest that there a UE 
 > with only v6 
 > PDP context requires one radio channel, while a UE with 
 > v4/v6 PDP contexts 
 > require two radio channels (regardless of the fact that the 
 > aggregate 
 > bandwidth usage is the same).
 > 
 > I don't know the radio technology well enough to to say whether this 
 > perception is true or not.

=> Ok, we can add some text to clarify this.

 > > => I've lost you here, how do you make the decision
 > > that there are few customers in the network? How
 > > does the UE know that? 
 > 
 > I don't know what (if any) signalling there is between the UE and the
 > network where some hints about network utilization could be 
 > piggybacked.  
 > Probably a lot.

=> None exists today. 

 > 
 > But even if there wasn't any, the first UE's could be 
 > programmed to open
 > both PDP contexts when they start, and possibly discard the 
 > other one if
 > it is not used in X minutes (or even keep it, no matter).

=> You're making assumptions about product rollouts and deployment
that are not necessarily correct. To be precise, you're assuming
that UE's will come in phases: "First UE's", seconds ...etc and
that they are synched with different scales of deployment.
This is not the case. Second, you assume that early networks
will be underutilised. This is also not necessarily a general
rule and depends on each operator.

 > > => What types of translation are there? We need IP
 > > address and port translation, hence NAPT-PT. 
 > 
 > No.

=> No what?

 > 
 > > The
 > > draft discusses how to install the translation
 > > state in the translator (i.e. installing it before 
 > > traffic goes through the translator). 
 > 
 > Yes, but for a very specific purpose only.

=> The draft discusses a specific case, it doesn't
_design_ a new translator for it. It discussed
the use of the existing translator.

 > > => It doesn't, but how can you restrict
 > > that in an IETF spec? If a UE doesn't get an IPv4 context, 
 > > it will go through the translator.
 > 
 > Please, we're discussing the 3GPP solutions document.  We as 
 > the WG can do
 > it any way we see fit.  Hopefully the solutions are 
 > reasonable though.  
 > If operators or vendors want to do something else, that's 
 > their problem
 > and fine too.
 > 
 > We should not write the document based on what people think 
 > might happen,
 > but what we think *should* happen 

=> What _should_ happen IMHO is that we explain how
the technology would apply to 3GPP, specify pros and
cons to our knowledge and stop right there. It is futile
to try to restrict something without having a protocol
fail if you attempt to do that restricted action. 
At least this is the aim of the existing keywords in 
RFC 2119. 

Hesham