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

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

Hi Juha, 

Thanks for bringing this up. A couple of comments below.

    not deploy IPv6-only UE's if they have a need 
 > to reach IPv4 services, and use application proxies 

=> To my knowledge, no one is arguing for IPv6-only
UEs. I tried to make that clear in the discussion.

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

=> Fine with me.

   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.

=> Agreed.

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

=> Agreed.

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

=> I was referring to the use of the term "channel" which
is not quite accurate. I'll send text.

Hesham

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