RE: 3gpp-analysis-07: (semi-)editorial issues

[<juha.wiljakka@nokia.com>]

 Hi, Pekka and others!

-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 16 December, 2003 12:54

Inline to a couple of issues that weren't maybe 100% clear..

On Wed, 10 Dec 2003 juha.wiljakka@nokia.com wrote:
 
> Only thing that somehow worries me is activating PDP contexts that
> may not be needed, i.e. extra usage of network resources. Should we
> add some note on that, e.g. draft-elmalki-sipping... states that

I note that there are two cases here:
 1) if you desire to operate the node as much in v6-only mode as 
possible (not opening v4 PDP context unless you have to), or
 2) if you desire to operate the node as much in v4-only mode as 
possible (not opening v6 PDP contexts unless you intend to use apps 
which use v6).

Which problem (or both?) are you worried of at this point?  

 JW: In my opinion, this sentence can be problematic: "it may also make sense to open both PDP contexts in advance, before they are used, because the activation of a context may take a relatively long time."  
It can lead to a situation in which we have activated hundreds of thousands extra, unused PDP contexts in the network and this is not good from network resource usage point of view. PDP context usage is quite much defined by used applications and I think we shouldn't write "open both types of PDP contexts in advance" recommendation. My recommendation is to leave the PDP context activation policy decided by the implementers / application developers.

At this point, I think 1) is premature but could be triggered with the
help of web proxies, etc. when the number of v6 users rises.  I guess 
the main problem is how the vendor could devise an algorithm or a 
"hint" on when to start relying on IPvXX PDP contexts.  This could be 
difficult.

The latter may not be a problem, because either the node is explicitly 
v6-enabled, or it has some apps (e.g. IMS subsystem, etc.) which could 
trigger the activation of v6 PDP context.

>                                              If IPv6 PDP contexts are
>     available and IPv6-in-IPv4 tunneling is needed, it is recommended
>     to activate an IPv6 PDP context and perform tunneling in the
>     network. This case is described in more detail in section 3.2.
> 
> ==> I don't understand this at all.  If IPv6 PDP context is available, it is
> available natively.  The UE doesn't know about v6-in-v4 tunneling in the
> first place.  So, isn't there some confusion here?  Or did the text mean to
> say something like, "If both v6 or v4 can be used, v6 should be preferred"? 
> Not sure if that's needed, but if so, consider e.g.:
> 
>     If an application can use both IPv4 and IPv6, and IPv6 PDP contexts are
>     available, it is preferable to try IPv6 communication first.
> 
> ... but this is already stated in the "As a general guideline..."
> -paragraph, so seems redundant?
> 
> JW: The current text is just saying that if IPv6 PDP contexts are
> available and IPv6-in-IPv4 tunneling is still needed somewhere
> between the UE and its peer node, it is better to activate IPv6 PDP
> context and do the tunneling in the network (instead of activating
> IPv4 PDP context and making tunneling in the UE). Anyway, the
> suggested way to go is not visible to the terminal at all, and
> communciation looks like native IPv6 communication to it.

Ok, then maybe reword to something like ? :

                                              IPv6 PDP contexts 
should be used even if that meant IPv6-in-IPv4 tunneling would be 
needed in the network (see section 3.2 for more details).  Note 
that this is transparent to the UE.

 JW: Looks quite ok. Maybe changing used -> preferred. 

>     An application running on a UE can identify whether the endpoint is
>     an IPv4 or IPv6 capable node by examining the destination address.
>     Alternatively, if a user supplies a name to be resolved, the DNS
>     may contain records sufficient to identify which protocol should be
>     used to initiate the connection with the endpoint. In dual stack
>     networks, one of the main concerns of an operator is the correct
>     address space and routing management. The operator must maintain
>     address spaces for both protocols. Public IPv4 addresses are often
>     a scarce resource for the operator and typically it is not possible
>     for a UE to have a globally unique IPv4 address (continuously)
>     allocated for its use. Use of private IPv4 addresses means use of
>     NATs when communicating with a peer node outside the operator's
>     network. In large networks, NAT systems can become very complex,
>     expensive and difficult to maintain.
> 
> ==> I don't see a direct relation of this paragraph to the recommendations
> in this document: the first part describes (incorrectly) how to get the
> address of the peer; the second part describes dual-stack considerations;
> the last part describes IPv4 NAT's. I suggest removing it.  The one thing
> that may make to preserve in some form is that the 3GPP operators typically
> use the private IPv4 addresses.
> 
> JW: Yep, rewording and text removal looks necessary. The first part
> can be removed, but I would like to retain some description on
> private address spaces and NAT. That should be described in our
> document (at least as a motivation to start to use IPv6).

Agreed, that should be good background material.

 JW: Yup, I will leave some "NAT problem" text.

> semi-editorial
> --------------
> 
>     can typically access both IPv4 and IPv6 services without additional
>     translators in the network. However, it is good to remember that
>     public IPv4 addresses are a scarce resource and in many cases IPv4
>     NATs are deployed. Public/global IP addresses are also needed for
>     peer-to-peer services: the node needs a public/global IP address
> 
> ==> s/a scarce resource/hard to come by/
> (they aren't really scarce as such, but it takes just a huge amount of
> paperwork etc. to get them..)
> 
> JW: No problems with that kind of wording, but I still would like to
> keep "scarce resource" term there. If you think about the growth
> rate of mobile phones, it is an impossible task to get a public IPv4
> address for all of them. If not today, after some time it certainly
> will be impossible...

I'm OK with both, even though I prefer "hard to come by" or something 
like that.  There are still over a billion addresses left, so they 
aren't really that _scarce_ :-).

The registries keep saying that there is no shortage of address space.  
I'd actually *like* to have a mobile operator request public v4 space
for all of its devices instead of doing NAT. :-)

 JW: Right.. It is more related to the allocation policy today, but will become even bigger problem in the future. Anyway, the fact is that private IPv4 addresses are used in most (at least European) GPRS nws. But no problems, I can use "hard to come by".

Next steps with 3GPP Analysis: because other tasks have kept me very busy during last couple of weeks, I will make revision -08 in January (I try to do that by mid-January). There are still some comments that I need to go through and reply to on the mailing list.

Merry x'mas!
		-Juha-