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

[<juha.wiljakka@nokia.com>]

 Hi, Hesham, Pekka et co.!

This issue has been open for a while (over one month...). I now try to summarize it and give some comments.

The issue raised by Pekka is about general description of IPv6 translators used in  a case in which an IPv6(-only) UE communicates with an IPv4(-only) node. And whether we are allowed to describe NAT-PT type of "general" solution to this problem. Pekka commented that it is not a good approach to use NAT-PT as a general purpose translation device for all kinds of traffic. And we should 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.

A long discussion by Hesham & Pekka followed  - there was quite a lot discussion of 3GPP architecture, radio resource usage, limitations in the number of different PDP contexts, etc. One concrete suggestion was to remove NAT64/NAT46 reference, does the wg think that it is a correct thing to do? Furthermore, this issue is clearly overlapping with the NAT-PT applicability team work. So we probably should make a reference to that draft once it is published.

-> I think that we can describe (that does not automatically mean strongly recommending that solution!) the NAT-PT type of solution for the general IPv6 -> IPv4 case in our document, and also refer to NAT-PT applicability draft. I personally think that clearly the most important 3GPP-related use case for NA(P)T-PT is the IMS interworking case (IMS scenario 1), that's a place where we clearly need a translator.

-> Hesham, you promised some text on PDP context / radio channel usage below - could you send some suggested text on the list?

Cheers,
	-Juha-

-----Original Message-----
From: ext Soliman Hesham [mailto:H.Soliman@flarion.com]
Sent: 22 July, 2003 13:37
To: 'Pekka Savola'
Cc: v6ops@ops.ietf.org
Subject: RE: 3gpp-analysis-04: use of NAT-PT in IPv6 UE -> IPv4 node




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