RE: 3gpp-analysis: Recommendation on tunneling in the UE

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 17 Nov 2003, Karim El-Malki (HF/EAB) wrote:
> There are some differences between unmanaged and 3gpp. For example the
> "gateway" (when it runs NAT) in Unmanaged scenarios puts some restrictions
> on the mechanisms that can be used. The same case does not apply to a
> 3gpp UE (which is not going to run NAT). So cases which Unmanaged considers
> of limited applicability are instead applicable here (e.g. single private
> v4 host connected to v6 ISP over a v4-only gateway/connection). IMO we should
> qualify the above statement further by saying that the 3gpp scenarios involve
> single priv. v4 host + ipv4 gateway cases, therefore some of the solutions
> which are recommended in Unmanaged are not equally recommended here. However
> on the other hand that seems to be a reason for considering them in the 3gpp
> analysis doc in the first place...

Note that we're referring to the unmanaged case only in the case where the
user's own 3GPP operator does not support v6 at all.  I don't think this
is something 3GPP analysis should be considering at all, so I'm OK with
dropping the references as well.

We'll try try to address the more generic 3GPP case below..

Could you suggest text/modifications?

> I don't think it is feasible to assume that we can easily set up
> configured tunnels in UEs without any user intervention. It would
> certainly need some automated mechanism which is probably what you mean
> by "easily manage the setup". 

Yep, that's what I mean.  But I disagree that we couldn't make it easy, 
requiring no user intervention.  Really, this shouldn't be any different 
from e.g. configuring the APN, or some other configuration stuff!

> Without having to specify a new one 

All this might need is some kind of "interface" to help the management 
and/or someone to figure out the gritty details..

> there
> are existing mechanisms for this that can make things easier and more
> transparent to users. I think it makes sense to refer to ISATAP as an
> existing solution that addresses this problem. I would suggest to add
> to the end of the parag above:
[...]

.. I think ISATAP is definitely an overkill in this specific scenario.  

After all, this is just a roaming case, when the operator (either local or
remote) doesn't support IPv6 PDP context at all, despite the
encouragement.  Not a majority case in any way -- the less complex we can
make it, the better.  A simple way to just set up a configured tunnel *)
would hit the nail on the head in this specific scenario IMHO.

*) the important point for the host is to get the knowledge of the v4
tunnel end-point somehow, and the server to get the IP address of the UE
(or the PC behind that).  I don't know 3GPP interactions in detail but
that should be pretty basic stuff (but maybe still worth spelling out in
the document).  The rest would be pretty much seamless.

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