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

From: <[email-masked]>
Date: Tue, 18 Nov 2003 15:36:25 +0200

Hi, Karim, Pekka and others,

trying to catch up this interesting discussion and making some kind of summary:
- not needing to refer to Unman scenarios&analysis
- Karim provides text on tunneling (to be updated to revision -08)
- Pekka's concerns on ISATAP providing more features than we need => in that case, we should document which parts of ISATAP are necessary for the 3GPP case, i.e. making a "subset of ISATAP" may be the solution? Shall you, Karim, also consider this point when writing your text?

Furthermore, I personally don't believe that configured tunnels make a feasible solution for this specific problem (even though they provide a good solution for some other scenarios). You must remember the high number of UEs and dynamic addressing. And any extra configuration effort isn't nice for the users. If you make the extra configurations using SMS (like configuring APN settings for different applications), that means one SMS more. The point is: IPv6 should be as easy as possible.

And still: we prefer native IPv6 communication and describe the "tunneling in the UE" as an *optional* thing (that won't be needed any more after GPRS networks start to widely support IPv6). That should not make harm to anybody.

Cheers,
	 -Juha-

P.S. All this discussion already shows to me that v6ops wg should start working on transition mechanisms. This wg needs to work on issues that are relevant for IPv6 deployment and that can help IPv6 getting deployed. Of course, the scenarios & analysis work is important, but we have done it already for so long time that we start to see which mechanisms are relevant (and which aren't). IMHO, getting ISATAP published as an RFC would be a good step towards that direction.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of ext Karim El-Malki (HF/EAB)
Sent: 18 November, 2003 14:47
To: 'Pekka Savola'
Cc: [email-masked]
Subject: RE: 3gpp-analysis: Recommendation on tunneling in the UE

 > 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:56:09 +0200 (EET)

> - Karim provides text on tunneling (to be updated to revision -08)

To be seen on the list.

> - Pekka's concerns on ISATAP providing more features than we need => in
> that case, we should document which parts of ISATAP are necessary for
> the 3GPP case, i.e. making a "subset of ISATAP" may be the solution?
> Shall you, Karim, also consider this point when writing your text?

In addition to providing more features than we need, ISATAP is also 
ill-fit to the "separate administrative domains" -model we have here, see 
the other thread.

> Furthermore, I personally don't believe that configured tunnels make a
> feasible solution for this specific problem (even though they provide a
> good solution for some other scenarios). You must remember the high
> number of UEs and dynamic addressing. And any extra configuration effort
> isn't nice for the users. If you make the extra configurations using SMS
> (like configuring APN settings for different applications), that means
> one SMS more. The point is: IPv6 should be as easy as possible.

This may be because of an assumption that the user might actually have to
*configure* something.  That's not necessarily the case.  Setting up
configured tunnels could be completely automatic.  Let's try to figure out
this in the separate thread, "manual config of UE tunnel".

> And still: we prefer native IPv6 communication and describe the
> "tunneling in the UE" as an *optional* thing (that won't be needed any
> more after GPRS networks start to widely support IPv6). That should not
> make harm to anybody.

Uhh.. doesn't this imply the opposite?  Even if optional, we specify that
ISATAP may be used, hence all the vendors implement ISATAP?  I don't see
that as a useful advice.

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