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

["Karim El-Malki (HF/EAB)" <karim.el-malki@ericsson.com>]

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

OK since I don't think that a comparable scenario is covered
in Unmanaged.

 > 
 > We'll try try to address the more generic 3GPP case below..
 > 
 > Could you suggest text/modifications?

OK, I'll send something out.

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

In fact the config of the APN etc. has been a problem all along
and we should not make it harder by overloading it with more
things to configure.

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

Let's look at the requirements so as to clarify the issue
once and for all. The required functions of a mechanism to solve
this are:

1 - The UE gets the IPv4 tunnel endpoint address in the operator's
    network
2 - The UE's IPv4 (probably private) tunnel endpoint address is
    communicated to the network endpoint
3 - The UE gets an IPv6 address known to the network tunnel endpoint

The UE and network tunnel endpoint are within the same IP (L3) domain.
2) can't be manually configured (since the UE's address is dynamically
assigned for most cases) and for all three functions the least config
you have to do in the UE, the better.

Taking the ISATAP example: 1) is solved by using DNS or manual config,
while 2) and 3) are solved by using the tunneled RA/RS mechanism. This
requires little work to implement and satisfies the above.
So it looks to me like ISATAP is not an overkill since it does not
do more than solve the above and requires little if any config.

/Karim