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

From: <[email-masked]>
Date: Wed, 26 Nov 2003 14:56:34 +0200

Hi Pekka,

> Certainly.  But this is no problem.  You can get that information
> using some means, e.g. SNMP.  I don't know which kind of interfaces
> 3GPP boxes have, and which kind management systems they connect to,
> but I'm pretty sure there can be ways to extract that information.

But this is a problem. The new solution has to be specified and implemented. This is not a trivial process. The boxes (and most probably are) of different vendors and implementing something like this and integrating it to the current networks is not a trivial task. 
So, theoretically everything is possible but practically this is not an option. Automatic tunneling would be much better fit in this case.

> 
> >  > if for no other reason, but because it's tunneled back from the 
> >  > foreign network.  
> > 
> > => I don't get this.
> 
> I mean, I understand foreign 3GPP operators use something 
> like L2TP to 
> transport the IPv4 packets back to the home operator, correct?  

Not quite. The mobility management and roaming are based on GPRS Tunneling Protocol. It works a bit different than how I would assume roaming works in the fixed network.
> The 
> home operator has to have some kind of policy to who will be allowed 
> in its network, i.e., when decapsulating the L2TP stream from the 
> foreign operator, the 3GPP operator should check the source addresses 
> of the packets (or at least do something to check that the 
> packets are 
> valid, for billing etc. reasons if for nothing else).

The policy is enforsed at the PDP Context activation time and GPRS attach time point. If the GGSN is at the home network (even when the user is roaming) the IP address is allocated from the home GGSN. Thus, if the PDP Context could be activated it means that the user has the right to use the IP services of that GGSN and the network where the GGSN is. There is a short summary how GPRS works at RFC3314.

> On the contrary, there is no reason to bless a solution (and impose
> the burden of the solution on everyone eelse) that some have chosen
> because they didn't think of alternative ways to achieve the result.
> 
> > => We can't assume that it is not well understood
> > because one person made a mistake.
> 
> I can read myself, and I can say for sure that it isn't well 
> understood. :-)
> 
> > It is implemented
> > on 4 different products that I know of (2 host platforms
> > and two router platforms) and are all interoperable. 
> 
> Implementatable & interoperable is VERY FAR from being well
> understood.

We have to look at this. However, I have come to the same conclusion about the implementation status of ISATAP. Maybe some vendors that have implemented ISATAP could indicate which version of the ISATAP they are shipping.

Cheers,

Jonne.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Nov 2003 15:43:46 +0200 (EET)

On Wed, 26 Nov 2003 [email-masked] wrote:
> But this is a problem. The new solution has to be specified and
> implemented. This is not a trivial process. The boxes (and most
> probably are) of different vendors and implementing something like
> this and integrating it to the current networks is not a trivial
> task.

Which implemenation are you refering to?  You probably wouldn't need 
to touch 3GPP systems; more probably, all you'd have to is to modify 
the tunnel router (which could be just a PC, a regular IPv6 router, or 
whatever).

The biggest task I see is identifying the methods which could be 
used to extract the information about IPv4 addresses from existing 
systems.

I'm sure e.g. billing and accounting systems *DO* exist ;-), so that 
may be one "hook" to the current systems.

> So, theoretically everything is possible but practically this is not
> an option. Automatic tunneling would be much better fit in this
> case.

Right.  I can see that in some cases, digging the information out of 
the network could be painful, and folks might want to avoid that.  
That's why I mentioned the second possibility: modification to the 
tunnel decapsulation code, that receiving a packet with a source IPv4 
address causes the allocation of a new configured tunnel interface, 
and triggers the advertisement of an IPv6 prefix.  Not a big deal.  
This could also be implemented as one "configured tunnel set-up 
pseudointerface" if one wishes.  

The point is that it's just a simple configured tunnel from the user's
perspective, and as much as possible, also from the ISP's perspective.

> Not quite. The mobility management and roaming are based on GPRS
> Tunneling Protocol. It works a bit different than how I would assume
> roaming works in the fixed network.

Oh, that's was what I meant; I assume the concepts are pretty similar.

> The policy is enforsed at the PDP Context activation time and GPRS
> attach time point. If the GGSN is at the home network (even when the
> user is roaming) the IP address is allocated from the home GGSN.
> Thus, if the PDP Context could be activated it means that the user
> has the right to use the IP services of that GGSN and the network
> where the GGSN is. There is a short summary how GPRS works at
> RFC3314.

Right.  So, the users, even when roaming, get the IP address from the 
home GGSN.  So the addresses used by the users are known at least by 
the home GGSN, and probably also some other accounting/billing 
databases etc.

If one doesn't provide the users a static IPv4 address, it may not be 
a requirement to provide a static IPv6 prefix (especially if the GGSNs 
etc. don't support v6 yet) either, right?

In such a case, it'd probably be enough to just give everyone a v6 
prefix either sequentially or depending on the v4 address, e.g. using 
the STEP "ad-hoc" mechanism.  

With that kind of "trick", the tunnel router would not have to get the
user/IP-address/v6-prefix information from anywhere, but the tunnels
would function as if they were configured tunnels, and the UE's would
not even know the tunnel router is doing some "magic tricks" to
generate configured tunnels.

But that v6 prefix advertisement can be done over a configured tunnel
(to some definition of "configured" at least :-) to the UE even with
dynamic addresses.
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings