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

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Tue, 18 Nov 2003 13:46:36 +0100

> 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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 16:39:52 +0200 (EET)

> 3 - The UE gets an IPv6 address known to the network tunnel endpoint

The last part is always a non-issue, as the UE can learn its address by 
a simple RA/RS mechanism, like any other IPv6 interface, so it could be 
dropped from the comparison.
 
> The UE and network tunnel endpoint are within the same IP (L3) domain.

Yes, they are, but they're in different administrative domains.  The 3GPP 
operator must treat the UE as a "hostile" host.  This is entirely 
different from e.g. normal enterprise networks, and which is why ISATAP is 
not very well suited to *this* particular task.

> assigned for most cases) 

Why not?  The 3GPP network has to know the address, because it assigns it 
to the UE.  Why couldn't it communicate it to the IPv6 box somehow?  Or 
where is this information stored, maybe it is retrievable?
 
> requires little work to implement and satisfies the above.

It seems to make that configured tunnels has about equal config for 1) and
3), and making 2) easier should be easily possible because the 3GPP
network must know the addresses of every user involved anyway.

> do more than solve the above and requires little if any config.

This is not accurate, but I'll respond to it in a separate thread.

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