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

[Soliman Hesham <H.Soliman@flarion.com>]

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

=> Perhaps we should remove the 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.

=> Your interpretation is correct but I'm not sure about
the benefit part.

 > 
 > 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, 

=> This is already assumed.

 >  - Not deploy IPv6-only UE's if they have a need to reach 
 > IPv4 services, and

=> This is also already assumed, more on this below.

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

=> Again this is already assumed. 

In draft-elmalki-v6ops ... which was presented in Vienna, 
we explained the case for NAT-PT. Basically, unlike ethernet, 
a "3GPP link" cannot be dual stacked. A UE can certainly be 
dual stacked, but a "link" (PDP context) can only run either
V4 or V6 but _not_ both. 
So, despite having a dual stack UE, you might only 
have one PDP context that supports v6 for example. To avoid
the cost of setting up another PDP context, a UE may continue
to use v6. For more details on the cost of setting up
a PDP context see draft-elmalki.

The other reason is IMS which mandates IPv6 for signalling 
and media.

Hesham