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

From: "Karim El-Malki (HF/EAB)" <[email-masked]>
Date: Mon, 17 Nov 2003 17:13:29 +0100

> Consider rewording:
 > =====
 >     However, the UE may attach to a 3GPP network, in which 
 > the Serving
 >     GPRS Support Node (SGSN), the GGSN, and the Home 
 > Location Register
 >     (HLR) support IPv4 PDP contexts, but do not support IPv6 PDP
 >     contexts. This may happen in early phases of IPv6 deployment.
 > 
 >     In theory, the user's own 3GPP operator might not 
 > support IPv6 at 
 >     all.  However, such scenario is considered out of scope of this 
 >     document; the considerations for Unmanaged networks would apply
 >     [UNMANSCEN] [UNMANAN].

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

 > 
 >     Presupposing some form of IPv6 support, there are two cases
 >     to consider when the visited network does not support IPv6 PDP 
 >     contexts:
 > 
 >        1. The UE is used as a "modem" with e.g. a laptop computer.
 >           The UE does not have to even support IPv6 PDP contexts,
 >           and all the transition issues are dealt with by the
 >           supporting equipment.
 > 
 >        2. The UE is used independently, running IPv6 applications,
 >           and would desire IPv6 connectivity.
 > 
 >     In both cases, it may be desirable to be able to create a tunnel
 >     between the UE (or the supporting equipment) and the user's 3GPP
 >     operator's IPv6 equipment.
 > 
 >     A way to easily manage the setup of a simple configured tunnel 
 >     would be sufficient, unless the basic IPv6 deployment in visited
 >     networks could be assumed and no tunneling would be 
 > needed at all.
 
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". Without having to specify a new one 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:

   A 3GPP operator that provides individual hosts with private IPv4
   addresses could install an ISATAP router for example, so that each
   of these hosts could obtain a globally routable IPv6 address.

/Karim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 01:04:11 +0200 (EET)

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

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

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 17 Nov 2003 15:42:32 -0800

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

If by "overkill" you mean that it *works better* than the other 
alternatives,
then I agree since ISATAP is  more automatic, agile and efficient than the
other alternatives. But, this would amount to an attarctive incentive 
and not
a negative as is usually implied by the term "overkill".

Otherwise, I have no idea how you could come up with the
term "overkill"; perhaps you could explain?

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 10:53:45 +0200 (EET)

On Mon, 17 Nov 2003, Fred Templin wrote:
> alternatives, then I agree since ISATAP is more automatic, agile and
> efficient than the other alternatives. But, this would amount to an
> attarctive incentive and not a negative as is usually implied by the
> term "overkill".

Yes, in this particular case, ISATAP provides more features than I believe
we need (such as, automatic tunneling between ISATAP nodes, prefix
delegation support, etc.).  Thus, a more simplified mechanism would be
better.

I'm also not confortable running ISATAP over administrative borders, as
has been suggested here.  This applies in a similar fashion and to a
lesser extent also to the unmanaged case where the ISP is doing NAT but
wanting to offer IPv6.

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 10:48:24 +0000

> lesser extent also to the unmanaged case where the ISP is doing NAT but

OK, so define ESATAP :)

I have always viewed ISATAP as an intra-site tool.   As such its use
does not impact the global architecture in the way that 6to4 or Teredo do,
which is a plus point in favour of its adoption...

Tim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 13:02:12 +0200 (EET)

> which is a plus point in favour of its adoption...

I'll respond, just in case you were serious.. :-)

The point of ISATAP (as I see it) to run it as an intra-site tool.  It
could be rather useful there, especially if there are VPNs and such where
you can't use VLANs etc..  However, rather than specifying something
similar that runs inter-domain, we should focus on determining what is
actually needed when running inter-domain.

I.e., start from a clean slate instead of trying to work ISATAP towards
being an inter-domain tool.

Note: ISATAP however is less intrusive for the global architecture, as it
uses the interface ID for its operations, does not require a prefix -- so
it's transparent to the rest of the 'net users, rather than 6to4/Teredo.
So, it's not IMHO totally fair to compare ISATAP to 6to4/Teredo w/ 
interdomain architecture.

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Nov 2003 11:13:42 +0000

> I'll respond, just in case you were serious.. :-)

I wasn't :)
 
> actually needed when running inter-domain.

I agree.  VLANs require an amount of administrative configuration, and
is more aimed at enabling whole subnets/links, whereas ISATAP is more
"opportunistic" and aimed at sparse/scattered hosts in a site.
 
> interdomain architecture.

True.  But we should consider that for any proposal too.  I'll add it
to the tunneling considerations draft (I propose widening the scope of
that draft to general tunneling rather than unmanaged network-specific).

Tim

---

From: Fred Templin <[email-masked]>
Date: Tue, 18 Nov 2003 09:59:37 -0800

>being an inter-domain tool.

No need; ISATAP is already good-to-go for the inter-domain case.

>interdomain architecture.

The point is not one of comparison; rather, ISATAP is a
complementary piece that completes the package.

Fred
[email-masked]