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

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 22 Jul 2003, Soliman Hesham wrote:
>  > > 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. 
>  > 
>  > Use another PDP context for IPv4.  (Which is what I tried to 
>  > advocate..)
>  > 
>  > > For more details on the cost of setting up
>  > > a PDP context see draft-elmalki.
>  > 
>  > I fail to see anything convincing there;
>  >  - PDP contexts require state in the 3GPP network, and
>  >  - PDP context require radio signalling or a channel
> 
> => There is also the time it takes to setup a PDP
> context, which is significant.

These need to be spelled out properly so we can make reasonable decisions.

>  > Lots of things require state in the network, including any kind of 
>  > protocol translator.  Protocol translators mitigate the need 
>  > for radio 
>  > channels, 
> 
> => This is not related to radio channels, it's related
> to the time and the resources consumed in the network.

This is very much related.  If you, using e.g. IPv6 proxies, make it so
that you basically never need IPv4, the time and resources consumed for
IPv4 in the network is much smaller.
 
>    and this is likely to be a problem only in the 
>  > short term, when 
>  > the number of radio signalling/channels is not a problem (a 
>  > small number 
>  > of customers).
> 
> => I don't understand the above statement. There is no
> relationship between the resources/time consumed to setup
> a context and the number of customers. 

There is.  draft-elmalki-* seems to give an impression that the absolute
number of state (for all users combined) is too much -- and my immediate
reaction to that is that by reducing the amount of concurrent state the
problem could be handled.

This also helps to a lesser extent wrt. time consumed to setup contexts
(if there are free resources == few customers in the network, you can set
up contexts pre-emptively).

>  > > The other reason is IMS which mandates IPv6 for signalling 
>  > > and media.
>  > 
>  > I thought draft-elmalki was primarily focused on solving the IMS 
>  > signalling problem -- which seems strictly separate from 
>  > this "NAT-PT for 
>  > general consumption" approach, and needs to be settled when 
>  > we figure out 
>  > which way to go in the IMS Scenario 1.
> 
> => They are tightly coupled. The draft first makes 
> the case for NAT-PT and then goes into how IMS would
> use it. If IMS requires translation anyway, NAT-PT
> will be used. Everything is running in the same
> network. 

Disagree.

If IMS requires translation, we may end up designing a translation which
suits IMS.  The previous sections don't indicate which translation will be
used for IMS, or that if IMS uses translation, the translation would also
be used in *any* other kind scenario.

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