Subject: RE: manual config of UE tunnel [RE: 3gpp-analysis: Recommendation on tunneling in the UE]

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

> On Tue, 18 Nov 2003, Karim El-Malki (HF/EAB) wrote:
 > > 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 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.

See previous email.

 > 
 > > 2) can't be manually configured (since the UE's address is 
 > dynamically
 > > 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?

We don't want to go there (likely to get stuck in complex GGSN
and 3gpp network internals).

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

See above. This can only make things very complex.
2) should not rely on special mechanisms in the 3gpp network.
It is no point to have a solution that requires changes to 3gpp
nodes since they might as well be upgraded to support v6!

/Karim

---

From: Jasminko Mulahusic <[email-masked]>
Date: Tue, 18 Nov 2003 16:42:52 +0100

> and 3gpp network internals).

<....>

> nodes since they might as well be upgraded to support v6!

which case are we trying to solve here? operators do wanna or do not 
wanna support ipv6? completely lost in the discussion...

jasminko

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 17:46:03 +0200 (EET)

Combining two answers:

[Jasko:]
> wanna support ipv6? completely lost in the discussion...

The cases:
 1) your home operator doesn't support v6 PDP contexts, but would like 
to offer some v6 service, or
 2) your home operator may support either v6 PDP contexts or some 
other v6 mechanisms, but the operator where you roam to doesn't

The case where the home operators supports nothing at all is out of 
scope (I think).

Hope this clarifies..

More inline..

> and 3gpp network internals).

We don't know until this has been analyzed.

This could really be no more complicated than sending a "I want to 
use IPv6 using a tunnel" SMS (or something like that), and then your 
phone and the tunnel endpoint would be configured automatically.

> nodes since they might as well be upgraded to support v6!

Would a modification be required?  I'm not so sure of that.  There 
must be some mechanisms to retrieve this information, either e.g. SNMP 
query or access to a database, or something.  That should be pretty 
much all you need.

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